[racket-dev] [plt] Push #24367: master branch updated

On 02/28/2012 01:56 PM, Robby Findler wrote:
> On Tue, Feb 28, 2012 at 2:43 PM, Ryan Culpepper<ryan at cs.utah.edu>  wrote:
>> On my machine before the change, "raco setup -D" took 8m13s real, 13m52s
>> user; after the change, it takes 4m0s real, 9m3s user.
> I guess you have a faster machine than I do. (Are you running the 64
> bit build or 32?)
>
> FWIW, the times I'm reporting are after your commit.
>
>> It's useful to look at the progress output, particularly the place that a
>> particular collection is scheduled on. Before, progress would stop on the
>> "macro-debugger" collection for a long time. Now, you can still see
>> individual places blocking for long periods of time by looking for long runs
>> where a place number is absent.
>>
>> On my machine, the "images" collection is scheduled on place 0, and it keeps
>> 0 occupied for a long time---until around when setup hits "scribblings".
>> Then place 2 is occupied by "gui-debugger", then 1 is occupied by
>> "macro-debugger". CPUs utilization drops to around 75% when it hits
>> "gui-debugger" and then to around 50% at "macro-debugger". Both of those
>> collections depend on "images". It drops again, briefly, around "scribble",
>> which is also around when "images" finishes---I'm not sure what that means.
>> It also takes a while to climb back to around 100%, and I'm not sure why
>> that happens either (possibly related to "scribble"/"scribblings"?).
>>
>> It seems like it should help to issue more collections while those few
>> block, but doing it naively (-j 5 or -j 6) doesn't work.
> I've put together something that reads .dep files and does a
> topological sort of the collections based on the dependencies (after
> breaking links to get rid of the cycles) and uses that to schedule the
> collections. I'm running some timing tests now.
>
> Robby
> _________________________
>    Racket Developers list:
>    http://lists.racket-lang.org/dev
I think this will be a great compromise between the status quo
and earlier work when I created a dependency graph for all .rkt files
in collects.

The dependencies between collections is likely to change less often.

How expensive is calculating the dependencies between collections?
I assume you have to look at the dependencies for every .rkt file in 
each collection. Yes?

Kevin