[Gcl-devel] Re: A ha

[Camm Maguire]

Greetings!

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