Re: [Texmacs-dev] TeXmacs profiling

[Joris van der Hoeven]

On Fri, 21 May 2004, David Allouche wrote:
> On Thu, May 20, 2004 at 11:44:44AM +0200, Joris van der Hoeven wrote:
> > > If you care about performance, here are a couple of things which can
> > > be to improve performance and that the profiling did not show because
> > > they are _distributed_ fat.
> > >
> > >   1. Get rid of the uneeded reference counting of function parameter,
> > >      especially in the fundation classes which are called zillions of
> > >      times.
> > >
> > >      A couple of years ago, I managed to get a 30% speedup that way, but
> > >      Joris rejected the code on stylistic grounds.
> >
> > I thought that you gained 10%. Anyway, I am not really opposed to doing
> > this for the base library functions. As I said in my previous email,
> > we probably should have a special 'T::in' type instead of 'const T&'.
> > I would have to check though that this is correctly supported by
> > other C++ compilers.
>
> I've been digging in old email. At that time (two years ago) I claimed a
> performance improvement of 15%

Well, that is still nice.

> The T::in where rep fields are passed should do it, and it would not
> require using those "const" you hate with a passion.

I do not really like T::in either, but one should carefully check that
one can really pass the rep field. I think that some additional logic
might be required in order to support that. In any case, one may start
by typedefing T::in as const T&.

> > > (well, there are exceptions, like the yet-to-be-merged patch which fix a
> > > serious performance bug with indentation handling).
> >
> > Yes, but... I think that we should rather systematically use structured
> > sections. This will remove the need for this whole indentation business.
> > I had no time for this reorganization yet though.
>
> Structured sections are no magic bullet. They will not remove the full
> retypesetting currently done when the indentation of a paragraph is
> changed.

When using structured sections, the no/yes-indent-after tags
are no longer needed, so they can be removed from the program.
In fact, this whole idea is quite dirty alltogether.
We will still keep the no/yes-indent-before tags,
but these ones are much easier to deal with.

> In addition, they will actually slow things down, since there are
> several algorithms which are quadradic in the depth of the document,
> involving lots of path reversions. Or did the path-decorated trees
> removed that issue?

No, but I do not think that they would slow things down, since the depth
of the document is usually proportional to the logarithm of its size.
In fact, in the present state, using recursive sections will speed-up
editing large documents by a huge amount, because it avoids the presence
of 'document' tags with many children. You may check that yourself by
selecting the structured-section package.

> > > Where you can make a difference are areas where theory and practice are
> > > different. I'm very curious to see cache profiling data for TeXmacs, I
> > > have always suspected that it spends most of its time in CPU cache
> > > faults.
> >
> > This is very probable, since data are allocated in a very random way.
> > However: how to remove that drawback?
>
> Removing needless indirections and data structure, especially the
> indirection with the array object of tree-like structures would be
> simple first step.

Could be. This would complicate accessing to the array though.
I would like to treat other optimizations first.

> More aggressive interning of recurring strings, like variable names in
> documents and common variable values would reduce the memory
> consumption, and if all interned names are stored in the same allocation
> pool, we can get the best cache misses.

Yes. That is also the idea behind more general atomic tree types.

> Generally, page-sized allocation pools for related objects may help
> improve locality. Since most of the time, most of a document structure
> is invariant (especially on big documents) it might be sufficient to
> build long-lived extensive data structures with good locality.

That may be done by copying the major data in spare time to unused memory.
However, it would probably be better to perform total compactification.
We need to carefully check all global data structures and the interaction
with Guile. Maybe implement a marking system too. Seems like
a time-consuming optimization.

In any case, the cache behaviour seems not to be that bad and your
experiences showed that the memory management is quite efficient too
(apart from the size of the generated code). It therefore seems that
the major performance problems should be searched elsewhere;
see the short list of possible improvements I posted a few days ago.