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

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 12 Oct 2019 05:57:09 +0200
> Cc: Kevin Layer <layer@franz.com>, 32729@debbugs.gnu.org, 32728@debbugs.gnu.org
> 
> (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?

> So it would seem that the Emacs filter method is just unnecessarily
> slow, which I've long suspected.  Creating the strings before calling
> the filter is probably what's taking quite a bit of this time, but the
> rest is taken up by garbage collecting as it spends 13 of these 20
> seconds doing that.
> 
> 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?

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.

> So for Emacs 28 I want to explore adding a new type of filter to
> processes: One that doesn't take a string argument, but which just
> inserts the data into the buffer, and then calls the filter with the
> region positions of what was inserted, which is just as powerful, but
> should allow streams to be 10x more efficient.

Doesn't the default filter already do that?