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: emacs takes exhorbitantly long to read long, one-line files. Date: Wed, 22 May 2013 17:51:49 +0300 Message-ID: <83ppwjt6d6.fsf@gnu.org> References: <87ppwn62yr.fsf@digitalsignallabs.com> <5199E19A.3020503@yandex.ru> <877git6hhv.fsf@digitalsignallabs.com> <519A08B2.7010106@yandex.ru> <87r4h1lo20.fsf@kwarm.red-bean.com> <838v39wsjz.fsf@gnu.org> <20891.10479.288862.913812@a1i15.kph.uni-mainz.de> <8361ycusiy.fsf@gnu.org> <20892.21326.472309.499588@a1i15.kph.uni-mainz.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1369234339 18845 80.91.229.3 (22 May 2013 14:52:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 May 2013 14:52:19 +0000 (UTC) Cc: kfogel@red-bean.com, dmantipov@yandex.ru, yates@digitalsignallabs.com, emacs-devel@gnu.org To: Ulrich Mueller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 22 16:52:18 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UfAOo-0006lH-9f for ged-emacs-devel@m.gmane.org; Wed, 22 May 2013 16:52:18 +0200 Original-Received: from localhost ([::1]:32941 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfAOn-0007F7-UR for ged-emacs-devel@m.gmane.org; Wed, 22 May 2013 10:52:17 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48622) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfAOg-0007Bk-Bg for emacs-devel@gnu.org; Wed, 22 May 2013 10:52:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UfAOb-00084R-Eh for emacs-devel@gnu.org; Wed, 22 May 2013 10:52:10 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:58265) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfAOb-00083H-6k for emacs-devel@gnu.org; Wed, 22 May 2013 10:52:05 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MN700F00FQ2X300@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Wed, 22 May 2013 17:51:54 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MN700FPLFYHXM00@a-mtaout23.012.net.il>; Wed, 22 May 2013 17:51:54 +0300 (IDT) In-reply-to: <20892.21326.472309.499588@a1i15.kph.uni-mainz.de> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:159728 Archived-At: > Date: Wed, 22 May 2013 07:10:38 +0200 > Cc: kfogel@red-bean.com, yates@digitalsignallabs.com, dmantipov@yandex.ru, > emacs-devel@gnu.org > From: Ulrich Mueller > > >>>>> On Tue, 21 May 2013, Eli Zaretskii wrote: > > >> Emacs 23.4: 4 s / 9 s > >> Emacs 24.3: 16 s / 34 s > >> > >> Is this degradation of performance expected? > > > I see no degradation in performance: both 4 sec and 6 sec, let alone > > 9 and 34, are the same as infinity. You cannot have any useful > > editing with such reaction times to a simple cursor movement > > command. It is therefore meaningless to compare such "performance" > > figures and draw any conclusions from them. > > Sure, the example with 16 MB in one line is unrealistic. I made it so, > simply because I wanted the times to be long enough to be measurable > with a stop watch. > > But wouldn't the factors between 23.4 and 24.3 be similar for more > realistic examples? Define "realistic". The definition I used (and still do) is "where Emacs 23 provided adequate behavior people wouldn't complain about." In each such case which I found or which was described to me, if Emacs 24 slowed things down so they got past the humanly perceptible delay threshold, I looked for and found optimizations that pushed Emacs 24 back below the threshold, where the times used by Emacs 23 and 24 could not be distinguished by humans. If you find "realistic examples" by that definition, please by all means report them as bugs. But it was never a goal to make the performance of the bidirectional display adequate where Emacs 23 wasn't, nor make it as inadequate as Emacs 23. That is another project, which needs to change display algorithms and design on a different level.