At Thu, 12 Jul 2012 13:08:21 -0400, Sam Tobin-Hochstadt wrote: > On Thu, Jul 12, 2012 at 11:49 AM, Matthew Flatt <[email protected]> wrote: > > > > I think the difference is GC variance due to the order that modules get > > loaded. If I try > > > > time racket -W debug -l racket/base -t tnull.rkt > > time racket -W debug -l racket/base -t rlnull.rkt > > > > then the times are extremely close, and I also see very similar GC times. > > I see these results too. That's good to know, but somewhat > frustrating for me, since there's not much I can do about this. Is > the difference here something that would be affected by setting the > nursery size at startup (if Racket had a way to do that)?
The difference becomes smaller with a 50MB nursery, but a 10MB nursery makes little difference (actually, a little slower on my machine). Change GEN0_INITIAL_SIZE in "newgc.c" if you want to play with this. More generally: Suppose that B depends on A. If you ask for B and the request eventually triggers A, then (parts of) B remain in the continuation while you do A. In contrast, if you ask for A first, then only the little plan to ask for B remains in the continuation while A is in progress. I believe that's the main difference here. In the long run, generational GC addresses the problem of parts of B sitting around during A, but this example is too short for a major GC to kick in. Also, if you use a 50MB nursery, then there's still some difference. Possibly it's a matter of other continuation-dependent things, such as parameter lookup; those things might be constant time in the long run, but you might see competing constants in the short run. Of course, we usually optimize for long-term performance, and it's sometimes tricky to balance short-term and long-term performance. Does the difference that you see still matter when a program does something useful? _________________________ Racket Developers list: http://lists.racket-lang.org/dev
