[Top][All Lists]

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

Re: [Texmacs-dev] Re: TeXmacs+Axiom

From: Joris van der Hoeven
Subject: Re: [Texmacs-dev] Re: TeXmacs+Axiom
Date: Fri, 25 May 2007 11:41:40 +0200
User-agent: Mutt/1.5.9i

Hi Josef,

On Thu, May 24, 2007 at 07:13:26PM +0200, Josef Weidendorfer wrote:
> > Basically, local retypesetting is done after every change.
> > When typesetting is done, we render, text close to the cursor first.
> > The rendering process is interrupted on a new keyboard event,
> > even though a minimal number of boxes are always redisplayed.
> I tried to come up with an extreme case to be able to reproduce how
> this works. I made up one single paragraph with around 100 lines and
> _lots_ of font changes (around 6 per line).
> Finally I got a latency of around 1/3 of a second from typing one char
> to display. This made some observations possible.

Yes, this sounds reasonable; it corresponds to about 30ms for
a more typical 10 lines paragraph with many font changes.

> * Most of the time, you append characters at the end of the paragraph.
> I imagined that this should be faster than typing in the middle, but
> this assumption obviously is wrong; the whole paragraph is relayouted
> even in this case. Of course, this is totally correct.

Yes, layout is heavily paragraph-based, so this is a natural minimal entity.

> We could cheat here: do only a relayout from the typing position to
> the end of the paragraph after every key, and a complete relayout
> only when idle.

Yes, I started to rewrite the typesetter in a more lazy way to do this.
However, this is really a gambling project: we'll know whether it works
after several months of work. Maybe it will just fail.

One of the things which I fear most is memory consumption:
the lasier, the more computations are remembered,
the more space is consumed, and ..., the more cache misses...

> However, I did not check the code if this is easily possible at all.
> * When typing faster than display latency, it can last a few seconds
> before you see anything of your typing. This means that:
>  (1) relayouting seems to be done for key press (otherwise it should
>      last a maximum of 0.3 seconds to display after fast typing)

At the moment, this correct. The point is that the correct handling of
the next keyboard event may require a typeset document (e.g. cursor movement).
Things might be made lasier though, or optimized when you type
alpha-numerical characters.

>  (2) any redrawing gets completely suppressed when texmacs is busy

No, TeXmacs will always attempt to redraw a few boxes close to your cursor.
However, when the typesetter is really slow, delays will be accumulated.

> And in more detail...
> samples  %        samples  %        image name         symbol name
> 5353     16.2473  6921     17.9561  texmacs.bin        hashmap_rep<string, 
> string>::bracket_ro(string)
> 3192      9.6883  3599      9.3374  texmacs.bin        
> string::operator()(int, int)
> 2371      7.1964  3002      7.7885  texmacs.bin        get_hyphens(string, 
> hashmap<string, string>)
> 1717      5.2114  2521      6.5406  texmacs.bin        hash(string)
> 1007      3.0564  1521      3.9461  texmacs.bin        operator new(unsigned 
> int)
> 972       2.9502  1128      2.9265  texmacs.bin        
> line_breaker_rep::process(list<int>)
> 812       2.4646  902       2.3402  texmacs.bin        
> string::operator==(char*)
> 804       2.4403  1379      3.5777  texmacs.bin        operator delete(void*)
> 775       2.3523  1000      2.5944  libguile.so.17.0.1 deval
> 696       2.1125  420       1.0897  texmacs.bin        
> tex_font_rep::get_extents(string, metric_struct (
> 671       2.0366  1194      3.0978  texmacs.bin        operator 
> new[](unsigned int)
> 608       1.8454  847       2.1975  texmacs.bin        
> string_rep::~string_rep()


> [Note that there is really nothing to optimize in the following
> functions if the above suggested optimizations can be done!]

Yep, I did similar profiling a few years ago and already did most of
the obvious optimizations...

Best wishes, Joris

reply via email to

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