Re: [Texmacs-dev] A first attempt to analyze TeXmacs performance behavior

[Joris van der Hoeven]

On Wed, 19 May 2004, David MENTRE wrote:
> I tried to understand the performance of TeXmacs. So I compiled texmacs,
> ran it and then analyzed the result using gprof.

Thanks for your help.

> It appears that those functions would have to be optimized in priority
> in order to improve the speed of TeXmacs. I don't know much about C++
> but I think that unfortunately some time consuming functions belong to
> the C++ language, like "operator new(unsigned int)" or
> "string::operator==(char*)".

These are not really C++ primitives in this case, but it seems quite
hard to improve the performance of these routines. In the past,
David actually tried two things:

  1) Using 'const T&' instead of 'T' arguments for all base library
     routines. Gain: 10% in time. It would even be better to create
     types T::in which directly pass the 'rep' field (thereby
     eliminating an indirection).

  2) Using Boehme's GC instead of our reference counting memory
     management system. David experienced no noticable gain and
     an additional 100% memory overhead, so I decided to forget
     about this track for a while.

> I did not tried to analyze the breakout per function. It is more
> difficult to analyze without knowing texmacs internals. And the output
> of the analysis should be taken with care (gprof makes some assumptions
> about subfunctions taking the same time each time they are called that
> can be wrong).

The important functions to measure are:
  * booting
  * font loading
  * anti-aliased glyph computations
  * overall typesetting
  * line-breaking
  * page-breaking
(There may be a few others though)

I think that it is still possible to gain on some of them:
  booting      : better Scheme than Guile.
  font loading : implementing some kind of cache system.
  glyphs       : cache.
                 in general: the caching mechanism should be abstracted
  typesetting  : better localization for big 'document' tags
                 in the future: more lazyness
  line-breaking: to be reimplemented for several reasons
  page-breaking: OK for the while; can be disabled when
                 editing anyway
  images       : OpenGL, imlib, etc. plug-ins

> In the long term, I think it would be necessary to have a systematic way
> to check those performance issues. The best way would be to write Scheme
> scripts that are launched at texmacs start, do some user behavior and
> then quit texmacs. Unfortunalty, I don't know how to write such a scheme
> script (however, if anybody on this list can help...).

It would also be interesting to be able to launch profiling after pushing
some button from within TeXmacs. That would allow us to measure the degree
of interactiveness.