From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#32728: bug#32729: Xemacs 23 times as fast as GNU Emacs Date: Sun, 13 Oct 2019 11:13:04 +0300 Message-ID: <83r23hkqr3.fsf@gnu.org> References: <871rviobu2.fsf@gnus.org> <83imouo1jp.fsf@gnu.org> <87y2xplufp.fsf@gnus.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="238436"; mail-complaints-to="usenet@blaine.gmane.org" Cc: layer@franz.com, benjamin.benninghofen@airbus.com, 32729@debbugs.gnu.org, 32728@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 13 10:14:14 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iJZ12-000ztO-Nl for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Oct 2019 10:14:12 +0200 Original-Received: from localhost ([::1]:38270 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJZ11-0001BL-HE for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Oct 2019 04:14:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49396) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJZ0u-0001Al-EW for bug-gnu-emacs@gnu.org; Sun, 13 Oct 2019 04:14:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iJZ0s-0004XA-Fz for bug-gnu-emacs@gnu.org; Sun, 13 Oct 2019 04:14:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54298) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iJZ0s-0004Wz-AD for bug-gnu-emacs@gnu.org; Sun, 13 Oct 2019 04:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iJZ0s-0003vT-1N for bug-gnu-emacs@gnu.org; Sun, 13 Oct 2019 04:14:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Oct 2019 08:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32728 X-GNU-PR-Package: emacs Original-Received: via spool by 32728-submit@debbugs.gnu.org id=B32728.157095440115023 (code B ref 32728); Sun, 13 Oct 2019 08:14:01 +0000 Original-Received: (at 32728) by debbugs.gnu.org; 13 Oct 2019 08:13:21 +0000 Original-Received: from localhost ([127.0.0.1]:34884 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iJZ0D-0003uE-3Q for submit@debbugs.gnu.org; Sun, 13 Oct 2019 04:13:21 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40287) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iJZ0B-0003tv-JR; Sun, 13 Oct 2019 04:13:20 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55395) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iJZ05-00040m-RG; Sun, 13 Oct 2019 04:13:13 -0400 Original-Received: from [176.228.60.248] (port=1844 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iJZ04-0004RJ-Vm; Sun, 13 Oct 2019 04:13:13 -0400 In-reply-to: <87y2xplufp.fsf@gnus.org> (message from Lars Ingebrigtsen on Sat, 12 Oct 2019 19:55:54 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:169107 Archived-At: > From: Lars Ingebrigtsen > Cc: benjamin.benninghofen@airbus.com, layer@franz.com, > 32729@debbugs.gnu.org, 32728@debbugs.gnu.org > Date: Sat, 12 Oct 2019 19:55:54 +0200 > > >> (Note: Don't visit the " *zeroes*" buffer after this, because that will > >> hang Emacs totally. I guess the long-line display problem hasn't been > >> fixed after all?) > > > > It's unrelated. Did you try to insert that into a unibyte buffer > > instead? > > Nope. Does Emacs need to do a lot of recomputing when going to > multibyte buffers? Of course: we try to display the multibyte text as characters, search for fonts, invoke bidi reordering, etc. > >> And it's a real world problem: When reading data from any network > >> source, you have to use filters because the protocol is usually based on > >> parsing the output to find out when it's over, so you can't use > >> sentinels. > > > > Why can't you use the default filter, and in the sentinel work on the > > buffer with the complete response? > > No sentinel is called, because the process status doesn't change, > typically. All the relevant network protocols do not close after having > "done something" (IMAP, HTTP, etc), but instead use in-protocol markers > to say that an operation is done. So a filter has to be used. OK, so not in sentinel, but in a timer or somesuch. > > Please also note that, GC aside, inserting stuff of size that is > > unknown in advance is not free, either: we need to enlarge the buffer > > text each time more stuff arrives. > > Yes, I was wondering about that -- how slow is resizing buffers, really? > Does Emacs rely on OS-level realloc that doesn't necessitate actually > copying all that data all the time? Not necessarily realloc, sometimes mmap or similar. And yes, this requires copying the data when the OS cannot grow the previous allocation, but instead gives us a memory block at another address. In most systems this copying is under the hood, but it does happen. > Also -- some of the networking operations know in advance how much data > is going to be received. For instance, when using non-chunked HTTP > (quite common when fetching "data", i.e., images, PDFs etc), we get the > content size in a header. Would it make sense to have a way to tell > Emacs about this in advance so that it could pre-size the buffer? We could provide a Lisp interface for such cases. The C implementation is in enlarge_buffer_text (but we need to remember the decoding of human-readable text, when applicable). However, I would begin by measuring the effect of this resizing on the time it takes to receive large amounts of data. Maybe other factors make this part negligible.