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

Previous Next

Full log

Message #45 received at 32728 <at> debbugs.gnu.org (full text, mbox):

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

Eli Zaretskii <eliz <at> gnu.org> writes:

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

accept_process_output inserts the data into the buffer and then calls
the callback with the region in question.  Well,
read_and_dispose_of_process_output, I guess...

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

It would avoid creating (and garbaging) the strings.

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

Oh!  That is curious indeed.  Are the Lisp_Object strings somehow
... special here when they never leave C land?  The speed differential
is completely repeatable...  hm...  Is the only difference that gc isn't
given a chance to run in the non-filter case?  Even if you subtract the
gc time, that doesn't explain the difference fully.

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

Previous Next

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