all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Improving emacs process performance (for free?)
@ 2004-05-26 21:23 Kim F. Storm
  2004-05-27  7:59 ` Eli Zaretskii
                   ` (3 more replies)
  0 siblings, 4 replies; 9+ messages in thread
From: Kim F. Storm @ 2004-05-26 21:23 UTC (permalink / raw)



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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Improving emacs process performance (for free?)
  2004-05-26 21:23 Improving emacs process performance (for free?) Kim F. Storm
@ 2004-05-27  7:59 ` Eli Zaretskii
  2004-05-27  9:02   ` Kim F. Storm
  2004-05-27 11:22 ` John Wiegley
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2004-05-27  7:59 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Improving emacs process performance (for free?)
  2004-05-27  7:59 ` Eli Zaretskii
@ 2004-05-27  9:02   ` Kim F. Storm
  2004-05-27 13:02     ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: Kim F. Storm @ 2004-05-27  9:02 UTC (permalink / raw)
  Cc: emacs-devel

"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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Improving emacs process performance (for free?)
  2004-05-26 21:23 Improving emacs process performance (for free?) Kim F. Storm
  2004-05-27  7:59 ` Eli Zaretskii
@ 2004-05-27 11:22 ` John Wiegley
  2004-05-28  9:17   ` Kim F. Storm
  2004-05-27 16:25 ` Andreas Schwab
  2004-05-29 17:03 ` Richard Stallman
  3 siblings, 1 reply; 9+ messages in thread
From: John Wiegley @ 2004-05-27 11:22 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Improving emacs process performance (for free?)
  2004-05-27  9:02   ` Kim F. Storm
@ 2004-05-27 13:02     ` Eli Zaretskii
  0 siblings, 0 replies; 9+ messages in thread
From: Eli Zaretskii @ 2004-05-27 13:02 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Improving emacs process performance (for free?)
  2004-05-26 21:23 Improving emacs process performance (for free?) Kim F. Storm
  2004-05-27  7:59 ` Eli Zaretskii
  2004-05-27 11:22 ` John Wiegley
@ 2004-05-27 16:25 ` Andreas Schwab
  2004-05-28  9:19   ` Kim F. Storm
  2004-05-29 17:03 ` Richard Stallman
  3 siblings, 1 reply; 9+ messages in thread
From: Andreas Schwab @ 2004-05-27 16:25 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Improving emacs process performance (for free?)
  2004-05-27 11:22 ` John Wiegley
@ 2004-05-28  9:17   ` Kim F. Storm
  0 siblings, 0 replies; 9+ messages in thread
From: Kim F. Storm @ 2004-05-28  9:17 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Improving emacs process performance (for free?)
  2004-05-27 16:25 ` Andreas Schwab
@ 2004-05-28  9:19   ` Kim F. Storm
  0 siblings, 0 replies; 9+ messages in thread
From: Kim F. Storm @ 2004-05-28  9:19 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Improving emacs process performance (for free?)
  2004-05-26 21:23 Improving emacs process performance (for free?) Kim F. Storm
                   ` (2 preceding siblings ...)
  2004-05-27 16:25 ` Andreas Schwab
@ 2004-05-29 17:03 ` Richard Stallman
  3 siblings, 0 replies; 9+ messages in thread
From: Richard Stallman @ 2004-05-29 17:03 UTC (permalink / raw)
  Cc: emacs-devel

    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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2004-05-29 17:03 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-05-26 21:23 Improving emacs process performance (for free?) Kim F. Storm
2004-05-27  7:59 ` Eli Zaretskii
2004-05-27  9:02   ` Kim F. Storm
2004-05-27 13:02     ` Eli Zaretskii
2004-05-27 11:22 ` John Wiegley
2004-05-28  9:17   ` Kim F. Storm
2004-05-27 16:25 ` Andreas Schwab
2004-05-28  9:19   ` Kim F. Storm
2004-05-29 17:03 ` Richard Stallman

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.