Re: [Texmacs-dev] TeXmacs profiling

[David Allouche]

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%

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

> > (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.

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?

> > 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.

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.

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.

-- 
                                                            -- ddaa