Greetings! I'm guessing from your other post that you are working with 2.7.0 aka master. Great! The build time is indeed slow, and this is among the main reasons why this is not released yet. But its not gc. The compiler has become very 'sophisticated' and inlines everything in terms of compressed lisp source. On top of this, it iterates on variable type collisions in tagbody and recursion, so computationally it is quite involved. It does produce superior code, but given how compile-time and runtime have been merged in recent usage, it needs to be able to cache previously compiled results, and this is not done yet.
Take care, Blake McBride <[email protected]> writes: > Perhaps you are right. I thought "run-gbc" was time in GC. In that case it > would have been drastic. The "gbc" time, while clearly not drastic, > is significant. Building GCL takes a bit of time. Given how much memory > machines have these days, bumping up the build-time memory footprint may > be worth it. > > Thanks for the response. > > Blake > > On Tue, Oct 28, 2014 at 7:27 PM, Camm Maguire <[email protected]> wrote: > > Greetings! > > Blake McBride <[email protected]> writes: > > > When building GCL I get messages like this: > > > > real time : 32.630 secs > > run-gbc time : 26.180 secs > > child run time : 2.259 secs > > gbc time : 4.119 secs > > > > I know what "real time" is. What do the other times represent? > > child time -- time spent in forked children, mostly gcc. > gbc time -- garbage collection time > run-gbc time -- time spent in GCL proper outside of garbage collection. > > > > > In particular, I am wondering about "run-gbc time" and "gbc time". If > "gbc" is garbage collection, I am wondering if there is some parameter > that > > can be set for building the system using a larger heap so that their > are fewer - or no - garbage collections. If my interpretations are > correct, > > this could drastically speed system build time. > > > > What the figures above show is that one might save ~12% if gc could be > eliminated entirely. Indeed, there are many settings which affect this > proportion, including the pre-allocation of various memory types. One > might have a large image for system building, and a minimal final image > for final use, as it is generally desirable to minimize the disk image > and not guess what the user's memory demands are likely to be. I'm > skeptical that 'drastic' savings are possible. > > Take care, > > > Blake McBride > > > > _______________________________________________ > > Gcl-devel mailing list > > [email protected] > > https://lists.gnu.org/mailman/listinfo/gcl-devel > > -- > Camm Maguire [email protected] > ========================================================================== > "The earth is but one country, and mankind its citizens." -- Baha'u'llah > -- Camm Maguire [email protected] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gcl-devel
