[racket-dev] A grab-bag of issues

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 <mflatt at 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 <mflatt at 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.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130705/0e77ab3c/attachment.html>