[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: A ha

From: Camm Maguire
Subject: [Gcl-devel] Re: A ha
Date: 04 Nov 2005 19:23:15 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2


Robert Boyer <address@hidden> writes:

> > One could have alternatively had the parent only fork one child to do bar
> > while it did foo, but then the issue you refer to would be possible.
> > Similarly with p-and and p-or, the parent memory image is completely quiet
> > while the children are running.
> Got it.
> > It also avoids the overhead of the stream creation unless needed, which is
> > unfortunately quite expensive at present.
> A wonderful thing to avoid a creating stream if not necessary.  Perhaps, you
> might discover an even better method than creating a new stream for
> communicating back the result.  For example, perhaps you could cannibalize
> (re-use) an old stream that happens to have been previously created and is
> still laying around.

Did a few performance measurements here.  One of the most expensive
items is that GCL uses generic stdio file pointers for its underlying
streams.  These call malloc, even on a simple open, and this hit to
the slowest part of our memory system (contiguous pages) is quite
regrettable.  Traditionally, GCL has sped this up a little bit by
using setbuf to allocate and deallocate the static buffer explicitly.
This cuts the allocation references down by about 1/3.  In the fork
stuff, we use no stream at all when writing just a pointer, and then
use stack (as opposed to heap) allocation for the file stream buffer
if required.  But there is at least one unavoidable malloc/free per
fopen/fclose which appears unavoidable.

Take care,

> Bob

Camm Maguire                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]