Improving emacs process performance (for free?)

Improving emacs process performance (for free?)

[Kim F. Storm]

I have previously reported the results of a test that I made to measure
emacs' process output handling speed, which indicated that we could
almost double the performance (at least on GNU/Linux) simply by
increasing the size of the read buffer from 1K to 10K.

I have been running with a buffer size of 10K for months now without
problems (on GNU/Linux), so I think I will install that change in CVS.

Can anybody see any problems making that change for all systems?

The buffer is allocated on the stack (with alloca), so it could be a
problem on systems with limited stack size -- do we still have such
systems?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Improving emacs process performance (for free?)

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: 26 May 2004 23:23:21 +0200
> 
> The buffer is allocated on the stack (with alloca), so it could be a
> problem on systems with limited stack size -- do we still have such
> systems?

How much limited is ``limited''?  Can you give a quantitative
estimate?

Re: Improving emacs process performance (for free?)

[Kim F. Storm]

"Eli Zaretskii" <eliz@gnu.org> writes:

> > From: storm@cua.dk (Kim F. Storm)
> > Date: 26 May 2004 23:23:21 +0200
> > 
> > The buffer is allocated on the stack (with alloca), so it could be a
> > problem on systems with limited stack size -- do we still have such
> > systems?
> 
> How much limited is ``limited''?  Can you give a quantitative
> estimate?

My change uses extra 9K on the stack in read_process_output.
Since that function can call a filter, which in turn calls
accept-process-output (etc), you may look at perhaps 3*9K
xtra on the stack.

Also, read_process_output calls decode_coding_string which may
allocate 16K on the stack.

So a minimum stack usage would be 3*10+16 = 46KB + what's allocated
elsewhere.  Pretty close to 64K if you ask me :-|

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Improving emacs process performance (for free?)

[John Wiegley]

storm@cua.dk (Kim F. Storm) writes:

> I have been running with a buffer size of 10K for months now without
> problems (on GNU/Linux), so I think I will install that change in
> CVS.
>
> Can anybody see any problems making that change for all systems?

Are there any latency issues this brings up?

John

Re: Improving emacs process performance (for free?)

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: 27 May 2004 11:02:30 +0200
> 
> So a minimum stack usage would be 3*10+16 = 46KB + what's allocated
> elsewhere.  Pretty close to 64K if you ask me :-|

Do we have some system supported by Emacs where the stack is merely a
64KB?  I think Emacs cannot run on such systems anyway; in the old
days when DJGPP (used to produce the DOS port) had a 256KB limit on
the stack, the Emacs binary was produced specially to have twice that
much, i.e. 512KB, because 256KB were not enough.

I think 512KB used by the DOS port is the smallest amount of stack we
have on any supported platform.

Re: Improving emacs process performance (for free?)

[Andreas Schwab]

storm@cua.dk (Kim F. Storm) writes:

> I have previously reported the results of a test that I made to measure
> emacs' process output handling speed, which indicated that we could
> almost double the performance (at least on GNU/Linux) simply by
> increasing the size of the read buffer from 1K to 10K.

Maybe using a page sized buffer would even be better.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Improving emacs process performance (for free?)

[Kim F. Storm]

John Wiegley <johnw@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > I have been running with a buffer size of 10K for months now without
> > problems (on GNU/Linux), so I think I will install that change in
> > CVS.
> >
> > Can anybody see any problems making that change for all systems?
> 
> Are there any latency issues this brings up?

Good point.

But that part of I/O is (normally) non-blocking, so I think it would
reduce latency, if anything.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Improving emacs process performance (for free?)

[Kim F. Storm]

Andreas Schwab <schwab@suse.de> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > I have previously reported the results of a test that I made to measure
> > emacs' process output handling speed, which indicated that we could
> > almost double the performance (at least on GNU/Linux) simply by
> > increasing the size of the read buffer from 1K to 10K.
> 
> Maybe using a page sized buffer would even be better.

Probably.

Or we can just use 4096 bytes for simplicity (that's still the page
size on most systems I think).  I don't have time to redo the
measurements, so let's just do that change.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Improving emacs process performance (for free?)

[Richard Stallman]

    The buffer is allocated on the stack (with alloca), so it could be a
    problem on systems with limited stack size -- do we still have such
    systems?

I don't think so.