From: "Jan Djärv" <jan.h.d@swipnet.se>
To: Eli Zaretskii <eliz@gnu.org>
Cc: mituharu@math.s.chiba-u.ac.jp, emacs-devel@gnu.org
Subject: Re: Display performance degradation
Date: Fri, 18 Dec 2009 17:47:22 +0100 [thread overview]
Message-ID: <4B2BB21A.8050709@swipnet.se> (raw)
In-Reply-To: <838wd1749d.fsf@gnu.org>
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.
next prev parent reply other threads:[~2009-12-18 16:47 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-17 2:49 Display performance degradation YAMAMOTO Mitsuharu
2009-12-17 7:39 ` Jan D.
2009-12-17 20:08 ` Eli Zaretskii
2009-12-18 16:47 ` Jan Djärv [this message]
2009-12-18 21:20 ` Eli Zaretskii
2010-01-02 11:05 ` Jan Djärv
2010-01-02 11:21 ` Eli Zaretskii
2010-01-02 14:31 ` Jan Djärv
2009-12-17 12:24 ` Kenichi Handa
2009-12-17 14:43 ` Chong Yidong
2009-12-18 3:53 ` Miles Bader
2009-12-17 16:42 ` Jan Djärv
2009-12-18 3:06 ` YAMAMOTO Mitsuharu
2009-12-18 5:46 ` Kenichi Handa
2009-12-19 2:56 ` YAMAMOTO Mitsuharu
2009-12-19 10:00 ` Andreas Schwab
2009-12-20 6:27 ` YAMAMOTO Mitsuharu
2009-12-21 1:17 ` Kenichi Handa
2009-12-21 2:11 ` Miles Bader
2009-12-21 2:31 ` Lennart Borgman
2009-12-21 3:05 ` Miles Bader
2009-12-21 3:08 ` Lennart Borgman
2009-12-21 3:44 ` Miles Bader
2009-12-21 3:54 ` Lennart Borgman
2009-12-21 4:16 ` Miles Bader
2009-12-21 4:18 ` Lennart Borgman
2010-01-06 19:46 ` Jan Djärv
2010-01-07 8:26 ` YAMAMOTO Mitsuharu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B2BB21A.8050709@swipnet.se \
--to=jan.h.d@swipnet.se \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=mituharu@math.s.chiba-u.ac.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).