<div dir="ltr"><div style>Okay, I finished doing some timing. The results suggest that the currently pushed version is probably the right thing (but for most cases, it would be fine to delete that code). Here are the numbers.</div> <div><br></div><div>With just 'time raco setup', after deleting all .zo files.</div><div><br></div><div style>with pre-compilation of 'racket' vs without</div>24m37.429s vs 0m39.229s<div>20m2.402s vs 0m45.841s<br> </div><div><br></div><div>using the more modern build: "time env PLT_SETUP_OPTIONS=-Dxi make" after deleting all .zo files:</div> <div><br></div><div>with pre-compilation of 'racket' vs without</div><div>19m0.320s vs 17m56.459s<br></div><div>17m31.638s vs 16m13.528s<br></div><div><br></div><div><div>With Matthew's change (commit 8be8057ff), pre-compilation of only racket/lib/collects/racket:<br> </div><div><br></div></div><div>15m56.670s<br></div><div>16m3.809s<br></div> <div><br></div><div style>I also tried re-ordering the list of collections on line 894 so that racket comes first and got these numbers:</div><div style><br></div><div style><div><div>16m8.225s<br></div><div>16m38.363s<br> </div></div><div><br></div><div style>I guess that these numbers are actually the same as the one before, just that there is noise in the numbers (but I don't know for sure).</div><div style><br></div><div style>Robby</div> <div><br></div><br></div><div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 5, 2013 at 12:40 PM, Matthew Flatt <span dir="ltr"><<a href="mailto:mflatt@cs.utah.edu" target="_blank">mflatt@cs.utah.edu</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">At Fri, 5 Jul 2013 10:58:39 -0500, Robby Findler wrote:<br> > On Thu, Jul 4, 2013 at 12:05 PM, Matthew Flatt <<a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>> wrote:<br> ><br> > > At Thu, 4 Jul 2013 12:52:10 -0400, Sam Tobin-Hochstadt wrote:<br> > > > All of these are about packages/the new repository organization.<br> > > ><br> > > > 0. I think we should have a new `#lang info` for info.rkt files --<br> > > > `setup/infotab` seems pretty arbitrary. I'll do this if no one<br> > > > objects.<br> > ><br> > > That sounds fine to me.<br> > ><br> > > > 1. Builds treat too much as core. Specifically, `raco setup`<br> > > > pre-builds some things single threaded, but too many:<br> > ><br> > > Yes. This is probably not too difficult to fix, but I haven't gotten to<br> > > it.<br> </div>> > <<a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a>><br> <div class="im">> ><br> ><br> > I had a quick look at this: the relevant code is these two lines (885 and<br> > 886 in setup-unit.rkt):<br> ><br> > (for/fold ([gcs 0]) ([cc (in-list (collection->ccs (list<br> > (string->path "racket"))))])<br> > (compile-cc cc 0)))<br> ><br> > I'm not sure of the right fix tho. I think we can either<br> ><br> > a) do nothing (since it causes no harm and you won't see this problem<br> > unless you are in a slightly strange situation of running the top-level<br> > makefile but already having the pkg links setup (I think))<br> ><br> > b) delete these two lines (since I think they are there only to make the<br> > parallel performance better, but that can be made better by just making<br> > 'racket' collections go first in parallel mode (I think))<br> ><br> > c) try to filter our non-collection-path 'racket's, something like this:<br> ><br> > (define (path-is-inside? candidate-parent candidate-child)<br> > (not (equal? (find-relative-path candidate-parent<br> > candidate-child)<br> > candidate-child)))<br> > (for/fold ([gcs 0]) ([cc (in-list (collection->ccs (list<br> > (string->path "racket"))))])<br> > (when (for/or ([cp (current-library-collections-paths)])<br> > (path-inside? cp (cc-name)))<br> > (compile-cc cc 0)))<br> ><br> > I guess b) is best, but I thought I'd check.<br> <br> </div>I think option (b) performed significantly worse back when Kevin tried<br> it, but it's possible that things have changed. Did you try it, yet?<br> <br> I was going to aim for something like option (c), but hopefully with a<br> simpler implementation.<br> <br> <br> <br> </blockquote></div><br></div></div>