At Tue, 29 Jan 2019 17:32:42 -0800 (PST), Alex Harsanyi wrote: > I mention this because the report recommends making > Racket CS the default, which I am very concerned about: > > > To maximize the maintenance benefits of Racket CS, it’s better to make it > > the default Racket variant sooner rather than later
I hope the context of this sentence is clear: The report is mostly about performance, and it says explicitly that we won't switch until performance is good enough (despite the maintenance benefits of switching). > As it stands now, the cases where RacketCS is slow have a significant impact > on my application. Do others see the same performance degradation in their > applications? I'm interested, too, but I expect others to report similar results. To connect your specific results more to the blog post, here are some things I took from looking at your program a few weeks ago: * A lot of code is generated from your source programs. Some of that seems to be Typed Racket; for example, 15% of the generated code is contracts to be used if typed code is called from an untyped context. (Thanks to Sam for helping with that experiment.) In any case, lots of generated code means even slower loading. * The plots for distribution builds show that TR-driven compilation gets slower in general. That by itself probably due to a combination of factors, but it certainly affects other programs that are written in TR. * The test suite involves significant I/O. As you mentioned, the test driving database operations, and those operations should be about the same. But the database is populated by parsing files, so slow I/O may be the bottleneck. -- 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 racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
