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: Tue, 21 May 2013 20:55:33 +0300 Message-ID: <8361ycusiy.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1369158965 7032 80.91.229.3 (21 May 2013 17:56:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 May 2013 17:56:05 +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 Tue May 21 19:56:03 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 1Ueqn5-0000dG-6w for ged-emacs-devel@m.gmane.org; Tue, 21 May 2013 19:56:03 +0200 Original-Received: from localhost ([::1]:50150 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ueqn4-0006wQ-U6 for ged-emacs-devel@m.gmane.org; Tue, 21 May 2013 13:56:02 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48767) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ueqmn-0006d5-Qu for emacs-devel@gnu.org; Tue, 21 May 2013 13:55:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ueqmm-00055L-JO for emacs-devel@gnu.org; Tue, 21 May 2013 13:55:45 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:39683) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ueqmm-000553-1F for emacs-devel@gnu.org; Tue, 21 May 2013 13:55:44 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MN500900TK8W200@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Tue, 21 May 2013 20:55:40 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MN5009J6TSRWJ10@a-mtaout20.012.net.il>; Tue, 21 May 2013 20:55:40 +0300 (IDT) In-reply-to: <20891.10479.288862.913812@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.166 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:159717 Archived-At: > Date: Tue, 21 May 2013 09:57:35 +0200 > Cc: Karl Fogel , > Randy Yates , dmantipov@yandex.ru, > emacs-devel@gnu.org > From: Ulrich Mueller > > > M-> > > C-p > > > and count the seconds it takes to perform the second command. > > I've done this test for a file with one line of 16 MB, and I get the > following times for the first and second commands (emacs -Q -nw in > an 80x24 xterm): > > 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. Emacs 24 has got a bidirectional display engine. Bidirectional display needs to do much more work than the previous unidirectional one in Emacs 23 and before. In a nutshell, where the unidirectional display simply incremented a pointer, the bidirectional display calls a complex function that does some very non-trivial processing based on the bidirectional class of each character. Now, this sounds scary, but really isn't. The bidirectional display was optimized so that in all the known uses where the old display provided reasonable performance, the new one does, too. While the bidi display is still slower than the unidirectional one, the optimizations keep the slowdown in check, such that the delays are below humanly perceptible threshold on reasonably modern and even fairly old machines. (I developed and debugged most of the code on a 7-year old machine that died less than a year ago.) By contrast, use cases such as the above, where the old code performs abysmally inadequately, were explicitly excluded from the scope of the optimizations, because it doesn't make sense to punish 99.9% of users on behalf of the rest. And that is what you see above. Emacs needs some non-trivial changes in display-related algorithms to adequately support very long lines. When those changes are designed and implemented, I promise you that the bidirectional display will keep up.