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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: benjamin.benninghofen@airbus.com,  layer@franz.com,
>   32729@debbugs.gnu.org,  32728@debbugs.gnu.org
> Date: Sun, 13 Oct 2019 19:36:47 +0200
> 
> So this is the design I want to do:
> 
> process-add-callback PROCESS FUNCTION
> process-remove-callback PROCESS FUNCTION
> 
> FUNCTION takes three parameters: The PROCESS and the start/end of the
> region inserted.  Perhaps it would make sense to do something with the
> return values -- if the function returns non-nil, then further callbacks
> are inhibited?

I don't understand what would trigger these callbacks, and how do you
specify the region in advance, without knowing what will be inserted.

Without understanding this, I don't think I see the utility, and most
important: why this would be faster.

> > 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.
> 
> Sure.  My simple dd test (without a filter) surprised me by being as
> fast as it was, so Emacs was able to grow that buffer quicker than I
> expected.  But it's also a pretty simple test case -- I can try to see
> what happens if I call enlarge_buffer_text to 1GB first and see what the
> effects are.

Btw, unlike what I originally implied, the default filter also
receives a Lisp string, so the question why by default reading dd
output is so much faster than when you define a non-default filter
function still stands.