Re: Display performance degradation

["Jan Djärv" <jan.h.d@swipnet.se>]

Eli Zaretskii skrev:
>> Date: Thu, 17 Dec 2009 08:39:50 +0100
>> From: "Jan D." <jan.h.d@swipnet.se>
>> Cc: emacs-devel@gnu.org
>>
>> The core problem is that Emacs internally doesn't track 
>> what is changed.  So it re-evaluates faces, fonts, menus, toolbars and 
>> so on, all the time before redisplay, and 99.99% of those times, nothing 
>> has changed.
> 
> Unless you are talking specifically about fonts (where I'm almost
> totally ignorant), the above is not really true.  The redisplay code
> includes quite a few shortcuts that try to reuse large parts of
> existing display, instead of redrawing it.
>

Sure, but for each redisplay there is a lot of updating of other stuff, that 
really doesn't need updating, like toll bars, menus and faces.


>> Emacs should to things all the way to get rid of this problem.  Now, 
>> when a menu for exampls is changed in lisp, the actual widgets on the 
>> screen are not changed until later.  So there is no connection between 
>> the change and the update on the screen.  So Emacs re-evaluates menus a 
>> lot of times just to be sure, in case something changed at the lisp 
>> level.  Instead the lisp change should lead to a screen change at once. 
> 
> I'm far from being an expert on this, but AFAIU, what you want is
> impossible without a total redesign of one of the main features of
> Emacs architecture: that Lisp code changes only the buffer text and
> various attributes of buffer text, while redisplay happens
> independently of that, when Emacs decides that ``it's a good time'' to
> do that.
> 

Redisplay is one thing, I'm not talking about that.  Rader the realization and 
merging of faces that happens when redisplay is to be done.

>>   That way we know that the menu is up to date and we don't have to 
>> re-evaluate it.
> 
> I think re-evaluation of menus is unrelated to redisplay.

Sure, but not to preformance.

> 
>> The same is true for faces, which I assume causes this problem.
> 
> Faces are not recomputed unless necessary.  Large portions of the
> display engine try very hard to avoid recomputing faces as much as
> possible, to the degree that sometimes you need to work very hard even
> to see the code which recomputes faces in action, because the various
> optimizations completely short-circuit it.

Hmm, faces are recomputed all the time.  If I start emacs like so:
% ./emacs -Q ../etc/tutorials/TUTORIAL.ja

Emacs does 102 calls to merge_face_vectors.  This may be needed, I haven't 
looked at this in detail.

What is strange though, is that if I scroll to the bottom of the buffer, 
another 62 calls to merge_face_vectors are done even if no face has changed.

	Jan D.