Re: [Texmacs-dev] TeXmacs profiling

[Joris van der Hoeven]

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

>   2. Remove uneeded indirections in critical tree-like data structures,
>      like trees, boxes, bridges, and generally all extensive data
>      structures which are used during typesetting.
>
> As far as algorithmic complexity and other quasi-mathematical issues are
> involved, TeXmacs is generally sane and Joris knows what he is doing.

Even though many things can be improved. Typesetting should in particular
become complete lazy. Also, the macro language should be detached from
the typesetting. However, all this presupposes further reorganizations,
even though we are getting closer and closer. On the negative side,
full lazyness and a detached macro language will probably have a cost too.
In other words: loading and typesetting a document for the first time
may become slightly slower, but the interactivity much higher.

By the way, a relatively easy temporary hack might be to split
big document tags (as bridges) in several parts using a binary tree.
This might considerably improve editing big documents in papyrus mode.

Another interesting thing which we might do in the future is to allow
for atomic trees which carry data of an internal data type (using
an L(t)<0). I expect this to accelerate some parts of the existing
code and this will especially be interesting for the upcoming
graphical primitives.

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

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