Also, I think you'll generally find that TR performs better than plain Racket when you don't have to interoperate with Racket (i.e., no contracts).
Robby On Mon, Aug 24, 2015 at 1:20 PM, Vincent St-Amour <[email protected]> wrote: > On Mon, 24 Aug 2015 11:24:33 -0400, > Rickard Andersson wrote: >> >> With regards to the measurements; as is obvious from this mailchain, I >> know about and use the `time` form. It hasn't skewed the results. >> >> Using the optimizing coach in DrRacket has yielded no results, really. I >> tried using it and there wasn't any advice on what to do for speedups >> (unless that advice isn't very discoverable, I don't know.). >> >> The only meaningful difference I discovered for TR was using 6.1.1, as >> apparently there was an optimization that'd been borked for 6.2.0 and >> onwards. >> >> I'm still curious about speed-ups with TR. I had expected it to perform >> better than Racket, but I guess the big win is that you get contracts >> with better performance instead of much faster, brittle code? > > TR can perform better than plain Racket, but not always. TR mostly > performs local optimizations that remove dispatch / checks in various > operations, so only programs using these operations will see any > improvements. Areas where you can expect wins are float- and > complex-number-intensive computations, as well as some data structure > accesses. > > Vincent > > -- > 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]. > For more options, visit https://groups.google.com/d/optout. -- 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]. For more options, visit https://groups.google.com/d/optout.
