Re: [Texmacs-dev] Performance questions, proposals, patches

[Joris van der Hoeven]

Hi Josef,

On Thu, 14 Oct 2004, Josef Weidendorfer wrote:
> On Thursday 14 October 2004 13:08, Joris van der Hoeven wrote:
> > On Wed, 13 Oct 2004, Josef Weidendorfer wrote:
> > >  least_upper_bound (rectangles l) {
> > No problem, I can do that. Is it really here that we get the stack
> > overflow? In that case, we might have to check why we do get such long
> > lists of rectangles.
>
> Originally, the stack overflow happens in requires_update() for me, but after
> I changed that function into iterative, it happened in least_upper_bound().
> I'm not sure why the list gets so long. But that should be easy to find out.
> Perhaps it's better to compact the list when it is getting longer than a
> given threeshould.

I checked the code and figured out that the change_log is only manipulated
in requires_update and least_upper_bound. However, the purpose of
requires_update is not to remove empty rectangles: it rather checks
which rectangles have changed and removes rectangles which did not change.
So the other optimization is incorrect. Making both routines iterative
should avoid the stack overflow though.

> > A better solution might be to use something like
> >
> >     if ((nr_painted%10 == 9) && dev->check_event (INPUT_EVENT)) return;
> >
> > I need to check though whether nr_painted cannot be increased during
> > such interruptions of the painting process though.
>
> Yes, may be better.

I did it like this and it seems to work.

> > Thanks a lot for all the work! I will apply your patches soon.
>
> Actually, I'm interested in making my profiling tool and visualization better.
> And texmacs is my current victim ;-)
>
> The tool is based on the instrumentation framework Valgrind, which is used for
> on-the-fly cache simulation and building up the call graph of unmodified
> binaries. And here, I only use the number of x86 instructions executed in
> functions to get some sorted list of hot points.
> Of course, optimizations should be checked afterwards for real run time
> improvement. But in contrast to OProfile alone, I'm getting exact call
> numbers and call arcs, and in contrast to GProf this is working with shared
> libraries. So I actually see e.g. how often a loop body in XCheckMaskEvent is
> executed by looking at annotated assembler in the visualization.

I also used Valgrind once, but I had no time to go more deeply inside.
One thing which would very much interest me is if you could detect memory
leaks in TeXmacs. There should be at least one (load a big file and
do several times Document -> Update -> All; the memory usage increases
quite much), but with the current lack of more sophisticated debugging
tools inside TeXmacs such leaks are hard to find. In the CVS version,
you may use "Tools -> Test -> Memory information" in order to see what
is going on.

Best wishes, Joris