Greetings! Robert Boyer <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gcl-devel
