Re: Display performance degradation

[Jan Djärv]

Eli Zaretskii skrev:
> > Date: Thu, 17 Dec 2009 08:39:50 +0100
> > From: "Jan D." <address@hidden>
> > Cc: address@hidden
> >
> > 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.