bug#32728: bug#32729: Xemacs 23 times as fast as GNU Emacs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> (benchmark-run 1 (call-process "dd" nil (get-buffer-create "
>> *zeroes*") nil "if=/dev/zero" "bs=1000" "count=1000000"))
>> => (4.703641145 0 0.0)
>> 
>> (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?

>> 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.

> 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?

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?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no