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

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Tue Feb 28 15:56:30 EST 2012

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.


Posted on the dev mailing list.