texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Texmacs-dev] TeXmacs profiling


From: David Allouche
Subject: Re: [Texmacs-dev] TeXmacs profiling
Date: Thu, 20 May 2004 11:14:22 +0200
User-agent: Mutt/1.5.5.1+cvs20040105i

On Wed, May 19, 2004 at 07:22:21PM +0200, David MENTRE wrote:
> Hello,
> 
> I tried to understand the performance of TeXmacs. So I compiled texmacs,
> ran it and then analyzed the result using gprof.
> 
> I compiled texmacs with following command:
> ./configure --prefix=/home/david/00-poubelle/texmacs --enable-debug CXX='g++ 
> -pg -fprofile-arcs'

For profiling you probably want to compile with at least _some_
optimizations.

> I used gcc suite 3.3.3 and TeXmacs 1.0.3.9.
> 
> I ran two test cases:
> 
>  1. - Launch texmacs
> 
>     - Run Help>Complete manuals>User manual
> 
>     - Run File>New
> 
>     - enter: a=b²+c²
>              Bienvenu sur TeXmacs.
> 
>     - save the buffer
> 
>     - quit texmacs
> 
> 
>  2. - Launch texmacs
> 
>     - Insert>Session>Shell
> 
>     - enter: env 
> 
>     - quit texmacs

What are those test cases meant to measure? The first one will mostly
measure full manual compilation, generation and rendering and second one
will mostly measure startup time.

If there is a specific operation you want to profile, you would have to
repeat it many times in a single run, or otherwise eliminate startup time
and other overheads.

> 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*)".

This profiling data is not helpful. It does not identify any bottleneck:
no function takes more than about 4% time and the big functions are
those which are called zillions of times because they are used all over
the source code.

> Moreover, in the above results, the guile library is not instrumented. I
> would probably be necessary to compile guile with the -pg option and
> include it statically in TeXmacs (I don't know how to do that).

Yes, that might be useful.

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.

  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.
(well, there are exceptions, like the yet-to-be-merged patch which fix a
serious performance bug with indentation handling).

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.

-- 
                                                            -- ddaa




reply via email to

[Prev in Thread] Current Thread [Next in Thread]