GNU bug report logs - #32728
Emacs slow when reading process output

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: layer <at> franz.com, 32729 <at> debbugs.gnu.org, benjamin.benninghofen <at> airbus.com, 32728 <at> debbugs.gnu.org
Subject: bug#32728: bug#32729: Xemacs 23 times as fast as GNU Emacs
Date: Mon, 14 Oct 2019 11:18:03 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: benjamin.benninghofen <at> airbus.com,  layer <at> franz.com,
>   32729 <at> debbugs.gnu.org,  32728 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.