Re: [Texmacs-dev] General efficiency of TeXmacs

[Norbert Nemec]

Joris van der Hoeven wrote:
> On Sun, Jun 14, 2009 at 05:11:23PM +0100, Norbert Nemec wrote:
>   
> > b) Profiling indicates that the program spends a tremendous amount of 
> > time on reference counting and deallocation. Moving to a garbage 
> > collector would significantly simplify the code and should result in 
> > quite some speedup. Especially for interactive programs, garbage 
> > collection is the fastest memory management strategy available since all 
> > the collecting is simply happening in idle time and the time critical 
> > code does not need to worry about deallocation at all.
> >     
>
> David did expermiments with that, but did not notice any important speedup.
> In addition, garbage collectors such as Boehm GC have other disadvantages.
> If we want to reduce the time spent on reference counting,
> then we should rather switch to const references, as said before.
>   
I must admit that my statement is mostly theoretical, based on the 
profiling data, looking at the code and realizing how many steps there 
are that the compiler cannot possibly optimize away. Making a prediction 
about absolute gain is hard without trying.

What did David do? Throw out reference counting completely? How much 
effort is that? I would like to try it out myself and do some actual 
measurements.

What disadvantages of garbage collection would be significant to 
TeXmacs? The main problem that I know of is that the memory requirements 
may be somewhat higher due to delayed deallocation. That, however, may 
easily be outweighed by the size-reduction of all objects by the counter 
itself.

How would const references help avoiding reference counting?

> > c) The string class is a significant bottleneck. Every time a (char*) is 
> > converted, the data is copied to a newly allocated location. In most 
> > cases, this could be avoided by simply copying a pointer. This would 
> > mean that the string_rep class would need to carry a flag on whether the 
> > space is "owned" (and should be deallocated) or just "borrowed". I 
> > certainly is a non-trivial task to sort this out, but I believe it would 
> > be the single-most-rewarding detail in optimizing for performance.
> >     
>
> One possibility I see is to replace all strings by global variables.
> However, as Max noticed, this introduces other problems. The C++ compiler
> sucks on this point; we had a similar problem in mathemagix.
> The only clean solution, a more systematic use of static variables,
> also introduces overhead (tests are inserted by the compiler
> for knowing whether a variables is used for the first time).
>   
That might solve the constant strings, but it won't work for strings 
passed from guile.

Greetings,
Norbert