From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Display performance degradation Date: Thu, 17 Dec 2009 22:08:14 +0200 Message-ID: <838wd1749d.fsf@gnu.org> References: <4B29E046.8050107@swipnet.se> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1261080421 31133 80.91.229.12 (17 Dec 2009 20:07:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 17 Dec 2009 20:07:01 +0000 (UTC) Cc: mituharu@math.s.chiba-u.ac.jp, emacs-devel@gnu.org To: "Jan D." Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 17 21:06:51 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NLMcV-00075u-Jt for ged-emacs-devel@m.gmane.org; Thu, 17 Dec 2009 21:06:43 +0100 Original-Received: from localhost ([127.0.0.1]:42510 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NLMcV-0008BY-HR for ged-emacs-devel@m.gmane.org; Thu, 17 Dec 2009 15:06:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NLMcO-00089c-35 for emacs-devel@gnu.org; Thu, 17 Dec 2009 15:06:36 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NLMcJ-000881-Dw for emacs-devel@gnu.org; Thu, 17 Dec 2009 15:06:35 -0500 Original-Received: from [199.232.76.173] (port=51395 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NLMcJ-00087x-8m for emacs-devel@gnu.org; Thu, 17 Dec 2009 15:06:31 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:32935) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NLMcI-0007d9-Ml for emacs-devel@gnu.org; Thu, 17 Dec 2009 15:06:31 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0KUT00B00BKYRO00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Thu, 17 Dec 2009 22:06:12 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.70.160.137]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KUT00BBGBU4V800@a-mtaout23.012.net.il>; Thu, 17 Dec 2009 22:06:05 +0200 (IST) In-reply-to: <4B29E046.8050107@swipnet.se> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:118680 Archived-At: > Date: Thu, 17 Dec 2009 08:39:50 +0100 > From: "Jan D." > 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. > 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. > 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. > 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.