Re: [Texmacs-dev] General efficiency of TeXmacs

[Joris van der Hoeven]

On Sun, Jun 14, 2009 at 09:47:47PM +0100, Norbert Nemec wrote:
> >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.

David tried replacing reference counting by the use of Boehm GC.
Disadvantages of this approach are the following:
  * More memory is used when using Boehm GC,
    since this GC is only conservative.
  * Our own memory allocator has good cache locality for
    the allocation of small objects (the most important ones).
Using a more strict GC would require the implementation of
a marking routine for every single TeXmacs class.
I doubt that this is worth the effort: const references
should be far more effective in gaining speed.
For our kind of usage, I think that reference counting
is basically a good scheme. More generally, I come to believe
that GC is evil and that one should never need it.

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

You will at least need a similar amount of space for marking objects.

> How would const references help avoiding reference counting?

Because only pointers to the objects will be passed in function calls;
objects won't be copied; this is standard when using C++...

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

There is a huge overhead for Guile routines anyway.
I do not think it is worth it to optimize that part.

Best wishes, Joris