From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Q on performance with 10000 faces Date: Mon, 22 May 2006 08:59:13 -0400 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1148302777 22409 80.91.229.2 (22 May 2006 12:59:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 22 May 2006 12:59:37 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 22 14:59:32 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FiA0R-00078T-Ll for ged-emacs-devel@m.gmane.org; Mon, 22 May 2006 14:59:32 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FiA0R-0001nV-8M for ged-emacs-devel@m.gmane.org; Mon, 22 May 2006 08:59:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FiA0G-0001nD-Qv for emacs-devel@gnu.org; Mon, 22 May 2006 08:59:20 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FiA0F-0001n1-4S for emacs-devel@gnu.org; Mon, 22 May 2006 08:59:20 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FiA0F-0001my-0v for emacs-devel@gnu.org; Mon, 22 May 2006 08:59:19 -0400 Original-Received: from [209.226.175.74] (helo=tomts20-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FiA4E-00025b-EL for emacs-devel@gnu.org; Mon, 22 May 2006 09:03:26 -0400 Original-Received: from localhost ([70.53.195.38]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060522125917.GHNN16051.tomts20-srv.bellnexxia.net@localhost>; Mon, 22 May 2006 08:59:17 -0400 Original-Received: by localhost (Postfix, from userid 20848) id 8B3C08258; Mon, 22 May 2006 08:59:13 -0400 (EDT) Original-To: "Drew Adams" In-Reply-To: (Drew Adams's message of "Sun, 21 May 2006 23:26:00 -0700") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:55031 Archived-At: >> Does this mean that Emacs cannot reasonably be expected to >> display 10000 face text-properties? > AFAIK, yes. Doing what you did (a) disables all possible display > optimizations that the redisplay engine has up its sleeve to speed up > the common cases, Indeed, changes in the face property take time. I wouldn't say that what he describes disables any particular optimization, but it makes them ineffective. > and (b) forces Emacs to traverse the 10000 text > properties for each character it is about to display. I don't see why the redisplay would have to traverse 10000 text properties for each char it is about to display. After all, there are 10000 chars each with a different face property, but each one only has one text property (or maybe a couple, but not 10000). > Don't do what? Use that many faces or something else also? It could be either don't use that many face-changes, or don't use that many faces. I suspect that the number of faces is what bogs you down which is why it also slows down redisplay of other windows. But I'm very non-knowledgeable about the redisplay code. > It's because even cursor motion, that usually takes a fast shortcut > through the redisplay code, requires to search all the text properties > in your situation. I don't see why that'd be the case. > I'm a little surprised that a frame that is not selected and has no current > activity (no cursor motion etc.), would continue to slow Emacs down just by > being displayed on the computer screen (and listening for input). Agreed. I think there is a missing redisplay optimization here (and I suspect that I sometimes suffer from a related missing optimization when I have 100 frames open). Stefan