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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

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

A timer wastes resources by triggering work when there's nothing to do,
and conversely, makes network connections sluggish by not having the
code happen immediately when there's data ready.

After thinking about this a bit more, I'm reminded of the problems I had
in this area when doing the NSM, because I really wanted to put a filter
on (some of) the processes, but I couldn't, because we only allow one
filter per process.

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?

Anyway, with this, the current filters can trivially be implemented as a
callback instead -- the filters would just be wrapped in a function that
does (funcall filter-function (buffer-substring start end)) so that
we don't need duplicated code for these mechanisms on the C level.  So
set-process-filter and related moves to the Lisp level...

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

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.

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