[Re-adding dev. Please reply all in the future.]
The relevant bits of the logs (for context, for those who did not get
the attachments) are:
Union of 30 types:
tr-timing: Fixed contract ids at 15740 last step: 0
gc: 0 total: 15116
tr-timing: Starting optimizer at 31028 last step:
15288 gc: 3166 total: 30404
tr-timing: Optimized at 31278 last step: 250
gc: 63 total: 30654
tr-timing: Finished, returning to Racket at 31278 last step: 0
gc: 0 total: 30654
Union of 31 types:
tr-timing: Fixed contract ids at 16270 last step: 0
gc: 0 total: 15615
tr-timing: Starting optimizer at 66269 last step:
49999 gc: 9246 total: 65614
tr-timing: Optimized at 66550 last step: 281
gc: 77 total: 65895
tr-timing: Finished, returning to Racket at 66550 last step: 0
gc: 0 total: 65895
The way I read it, it's not the optimizer taking 3 times as much time in
the second case, but the step before. I.e., what happens between fixing
contract ids and launching the optimizer. Which is these two lines in
TR's `core.rkt`:
[(before-code ...) (change-provide-fixups (flatten-all-begins
pre-before-code))]
[(after-code ...) (change-provide-fixups (flatten-all-begins
pre-after-code))]
(If you want to confirm that the optimizer is not at fault, you change
change the #lang line to "#lang typed/racket #:no-optimize", which turns
off the optimizer altogether.)
I'll look into `change-provide-fixups`, but it would be really helpful
if you could share your problematic program, or at least a fragment that
exhibits this behavior. Otherwise, I don't have a good example program
to measure.
Vincent
On Wed, 09 Sep 2015 18:09:00 -0500,
Antonio Leitao wrote:
>
> Hi,
>
> On Wed, Sep 9, 2015 at 11:25 PM, Vincent St-Amour
> <[email protected]> wrote:
>
> [Re-adding dev]
>
> Did you observe similar increases with the previous version of
> Racket
> (i.e. before my fix)? Maybe with previous versions of your program
> (that
> didn't trigger the SC bug you reported earlier).
>
> The fix I pushed *does* reduce the caching done during contract
> generation, which could explain a performance regression. But if the
> fix
> caused the program to go from "erroring" to "taking a long time to
> compile", the fix may just have uncovered an existing performance
> issue
> that the error was masking.
>
> The question at this point is: where is that time being spent?
>
> To find out:
> - Start without any compiled files for your program (i.e. clear out
> the
> relevant `compiled` directories)
> - Run: PLTSTDERR=debug@tr-timing raco make my-program.rkt
>
> That should dump some timing info that shows where time is being
> spent
> in TR.
>
> Depending on the results, there may be different solutions.
>
>
>
> Attached you'll find two dumps. One (out.txt) is for a union of 30
> types. The other (out2.txt) is for a similar union but containing 31
> types. It seems to me the problem is in the optimizer but the dumps do
> now show much information regarding this final step.
>
> Does this help you identify the problem?
>
> Best,
> António.
--
You received this message because you are subscribed to the Google Groups
"Racket Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-dev/m2y4geckrv.wl-stamourv%40eecs.northwestern.edu.
For more options, visit https://groups.google.com/d/optout.
