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