Awesome. Also I didn’t know you could include ‘#%place like that. Nate
> On Nov 25, 2020, at 9:41 PM, Sam Tobin-Hochstadt <[email protected]> wrote: > > Here's an in-progress PR: https://github.com/racket/racket/pull/3518 > > With this, your simple test takes about 150ms with `racket/place` and > 50ms with `racket/place/dynamic`. For comparison, just having the > submodule depend on `racket/base` gives a time of about 42 ms, and > just `racket/kernel` is about 12ms. > > Sam > >> On Tue, Nov 24, 2020 at 2:04 PM Sam Tobin-Hochstadt >> <[email protected]> wrote: >> >> th-place is used if places are not enabled when Racket is built (this is the >> default on some platforms). >> >> I'm making progress on shrinking this, hopefully I'll have a patch done soon. >> >> One thing to note is that '#%place can be required directly and will have >> almost no start-up cost. >> >> Sam >> >> Sam >> >>> On Tue, Nov 24, 2020, 1:58 PM Nathaniel W Griswold <[email protected]> >>> wrote: >>> >>> I noticed i am using the pl- functions so I replaced th-place.rkt with a >>> stub and saw more time shaved off, this time about 15ms for each >>> racket/place import. >>> >>> Under what circumstances is th-place used instead of '#%place and needed? >>> >>> Nate >>> >>>> On Nov 24, 2020, at 12:31 PM, Nathaniel W Griswold <[email protected]> >>>> wrote: >>> >>> I seem to remember there being some global namespace. Since every >>> reasonable place will require racket/place, might it be possible to make >>> the racket/place import a special case and stick it in the global space, to >>> improve place setup time? It would be nice to be able to only set up >>> racket/place one time instead of once for each place. >>> >>> Nate >>> >>>> On Nov 24, 2020, at 12:24 PM, Nathaniel W Griswold <[email protected]> >>>> wrote: >>> >>> Actually, it cuts about 20-25ms off of a single import. Down from 185ms to >>> 165ms for me. 50ms off my startup time of my app on average, since i >>> basically stack the import twice and sync on the place being ready. >>> >>> Might be worth including and seeing if there’s anything else that can be >>> shaved off. >>> >>> Nate >>> >>>> On Nov 24, 2020, at 12:09 PM, Nathaniel W Griswold <[email protected]> >>>> wrote: >>> >>> I checked into it a bit. >>> >>> racket/fixnum, racket/flonum, and racket/vector are needed by >>> “private/th-place.rkt”, which is required by racket/place. Not sure why >>> DrRacket is saying that it’s not needed. >>> >>> racket/runtime-path does not appear to be needed. >>> >>> I tried removing racket/runtime-path and racket/match but didn’t see any >>> performance gains. It appears the delay is elsewhere. >>> >>> Nate >>> >>>> On Nov 24, 2020, at 9:52 AM, Robby Findler <[email protected]> >>>> wrote: >>> >>> DrRacket thinks that there are no references to a number of the requires in >>> racket/place, including racket/fixnum, racket/flonum, racket/vector, and >>> racket/runtime-path. Not sure if that's an error on DrRacket's part (and I >>> don't see why those would be needed for their effects). >>> >>> Also, the only use of racket/match seems to be this, which seems simple to >>> rewrite out. >>> >>> (match name >>> [(? symbol?) `(submod (quote ,name) ,submod-name)] >>> [(? path?) `(submod ,name ,submod-name)] >>> [`(,p ,s ...) `(submod ,(if (symbol? p) `(quote ,p) p) ,@s >>> ,submod-name)]) >>> >>> Robby >>> >>> >>> On Tue, Nov 24, 2020 at 8:58 AM Nate Griswold <[email protected]> >>> wrote: >>>> >>>> Oh, interesting. So compilation breaks the submodule out from the modules >>>> if possible? >>>> >>>> So anyway, it sounds like breaking my modules out into separate files will >>>> improve performance in most cases. >>>> >>>> Unfortunately, i need racket/place in the module that is my startup >>>> bottleneck. If i modify the previous program to require racket/place and >>>> compile, it takes around 180ms. >>>> >>>> This is about what i can expect for a module that requires racket/place, >>>> then? >>>> >>>> Nate >>>> >>>> >>>> On Tue, Nov 24, 2020 at 8:48 AM Matthew Flatt <[email protected]> wrote: >>>>> >>>>> Just to elaborate a little more: >>>>> >>>>> The difference is because the `test` submodule can be loaded >>>>> independently from the compiled form. Loading the submodule from source >>>>> requires loading the enclosing module, too (which depends on >>>>> `racket/place` and more). >>>>> >>>>> At Tue, 24 Nov 2020 08:46:12 -0600, Nate Griswold wrote: >>>>>> Awesome, thanks! >>>>>> >>>>>> Nate >>>>>> >>>>>> >>>>>> On Tue, Nov 24, 2020 at 8:44 AM Sam Tobin-Hochstadt >>>>>> <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Almost certainly the problem is expansion time. If I run that program >>>>>>> on my machine, it takes about 200 ms. But if I compile the file to zo >>>>>>> first with `raco make`, then it takes about 40 ms, basically identical >>>>>>> to `racket/base`. >>>>>>> >>>>>>> Sam >>>>>>> >>>>>>> On Tue, Nov 24, 2020 at 9:39 AM Nate Griswold <[email protected]> >>>>>>> wrote: >>>>>>>> >>>>>>>> Oops, i am having some issues with not getting to the list from my >>>>>>>> other >>>>>>> email address. Here is a reply i sent for the record. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Thank you, Matthew. >>>>>>>> >>>>>>>> The following code takes around 250ms on my machine. Any idea why? I >>>>>>>> was >>>>>>> expecting it to be fast since the module is based on racket/base. >>>>>>>> >>>>>>>> #lang racket/base >>>>>>>> >>>>>>>> (require syntax/location) >>>>>>>> (require racket/place) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> (module test racket/base >>>>>>>> (provide place-main) >>>>>>>> racket >>>>>>>> (define (place-main pch) >>>>>>>> (void))) >>>>>>>> >>>>>>>> (time (place-wait (dynamic-place (quote-module-path test) >>>>>>>> 'place-main))) >>>>>>>> >>>>>>>> Nate >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Nov 24, 2020 at 8:35 AM Nathaniel W Griswold >>>>>>> <[email protected]> wrote: >>>>>>>>> >>>>>>>>> Thank you, Matthew. >>>>>>>>> >>>>>>>>> The following code takes around 250ms on my machine. Any idea why? I >>>>>>> was expecting it to be fast since the module is based on racket/base. >>>>>>>>> >>>>>>>>> #lang racket/base >>>>>>>>> >>>>>>>>> (require syntax/location) >>>>>>>>> (require racket/place) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> (module test racket/base >>>>>>>>> (provide place-main) >>>>>>>>> racket >>>>>>>>> (define (place-main pch) >>>>>>>>> (void))) >>>>>>>>> >>>>>>>>> (time (place-wait (dynamic-place (quote-module-path test) >>>>>>>>> 'place-main))) >>>>>>>>> >>>>>>>>> Nate >>>>>>>>> >>>>>>>>> On Nov 24, 2020, at 8:16 AM, Matthew Flatt <[email protected]> wrote: >>>>>>>>> >>>>>>>>> The bottleneck for place startup is loading modules into the new >>>>>>>>> place, >>>>>>>>> including modules like `racket/base`. >>>>>>>>> >>>>>>>>> For example, >>>>>>>>> >>>>>>>>> (place-wait (dynamic-place 'racket 'void)) >>>>>>>>> >>>>>>>>> takes around 200ms on my machine, while >>>>>>>>> >>>>>>>>> (place-wait (dynamic-place 'racket/base 'void)) >>>>>>>>> >>>>>>>>> takes around 30ms and >>>>>>>>> >>>>>>>>> (place-wait (dynamic-place 'racket/kernel 'void)) >>>>>>>>> >>>>>>>>> takes around 10ms. >>>>>>>>> >>>>>>>>> It sounds like you're already aware that the complexity of the module >>>>>>>>> loaded into a place matters, though. Beyond using a minimal set of >>>>>>>>> modules, I don't have any way to make place startup faster. >>>>>>>>> >>>>>>>>> Matthew >>>>>>>>> >>>>>>>>> At Tue, 24 Nov 2020 05:04:19 -0600, Nate Griswold wrote: >>>>>>>>> >>>>>>>>> Is there any way to make places startup faster? Even if i do an >>>>>>>>> explicit >>>>>>>>> round trip using place-channel-put and place-channel-get on both >>>>>>>>> sides, >>>>>>> it >>>>>>>>> takes on the order of centiseconds for near empty places to start up. >>>>>>>>> >>>>>>>>> My program requires the threads for a couple places to be set up >>>>>>>>> before >>>>>>> it >>>>>>>>> can operate, so this impacts my startup time by quite a bit. >>>>>>>>> >>>>>>>>> I have one place that has a very simple module and one place with a >>>>>>>>> more >>>>>>>>> complicated module. Is there some sequence that i should do things in >>>>>>> for >>>>>>>>> the minimal startup time? It seems nothing i do really helps much. >>>>>>>>> >>>>>>>>> Nate >>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups >>>>>>>>> "Racket Users" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>>>> an >>>>>>>>> email to [email protected]. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> >>>>>>> >>>>>> https://groups.google.com/d/msgid/racket-users/CAM-xLPpvfCHHDDpfNmuTWQOyfYfEJ7v >>>>>>>>> m1c_dS7nj3FxaEFVm2Q%40mail.gmail.com. >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Racket Users" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>>>> an email to [email protected]. >>>>>>>> To view this discussion on the web visit >>>>>>> >>>>>> https://groups.google.com/d/msgid/racket-users/CAM-xLPqtJrem4j%3DUi3fbrduoahsXC >>>>>> NNA2JPuB0Tt9dissiu5KA%40mail.gmail.com >>>>>>> . >>>>>>> >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google Groups >>>>>> "Racket Users" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send an >>>>>> email to [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/racket-users/CAM-xLPqVgEBvrRzjU7%3DX_h3Wy_YUH >>>>>> 11G6CX5%2BKjSct26pi3oEA%40mail.gmail.com. >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "Racket Users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an >>>> email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/racket-users/CAM-xLPoLD6N%3Dwep%2Bed5UGduA7mZ-SaYxFJ9VbqM78CppMG3m2w%40mail.gmail.com. >>> >>> >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Racket Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/racket-users/7AE1B364-8DE1-435C-8AA2-EBCFE078040D%40manicmind.earth. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/550AD17A-B2C1-4263-91E0-AD5F52299503%40manicmind.earth.
