On Wednesday, January 30, 2019 at 10:53:21 PM UTC+8, Matthew Flatt wrote: > > 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). >
Thanks for clarifying that. My interpretation of the report was that, while some performance problems exist, these are acceptable and RacketCS should become Racket 7.3 (or 8.0) > > [...] > > 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. Do you mean (1) that the source code is large or (2) that the generated byte-code or machine code is unexpectedly large given the size of the sources? If (1), I don't consider it large, at least not when compared to the size of the programs I write and develop at work. Also, the program would be twice as large if I had the time to add all the features I would like to :-) If (2), is there a way to structure it such that less code is generated from these sources? Is there a "best practices" document for structuring Racket 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. > I always assumed that the contracts generated when TR code is used from untyped Racket would be the same as the ones written by hand if the module would be untyped and had contracts on the same exported functions. Is this not the case? Is there some documentation on how to measure the amount of code used by contracts (the 15% value you mention above)? I experimented with TR for a few things and left them in the code base, but if they create significant performance issues, I can convert them to untyped Racket easily. [...] > > * 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. > > I am not sure what "significant" means, but the tests don't read and write a large amount of data: * The total test data size is less than 10Mb: the largest file is 4Mb, the second largest is 1.3Mb and the third largest is 500Kb and the fourth is 400Kb; The remaining files are less than 300Kb each, and half of them are under 100Kb. These are binary files, read in a byte vector in one go, using `file->bytes`. * Some tests also read in a SQL schema file from disk, and this is 50Kb in size, plus a handful of small SQL files read in once only for each of the 6 test programs. * For most tests, the database is created in memory, so, while there are a lot of SQL statements run, they don't create any disk IO. * One test that uses on-disk databases reads in about 12 SQL files, less than 5Kb each. The database IO is done by the SQLite library, not by racket. * Another test using on-disk databases does no IO apart from SQLite (i.e the Racket code just runs SQL statements). * The third test using on-disk databases writes about 20 small files to disk and reads half of them back in. I would be happy to help you identify where the performance degradation between Racket 7.1 and CS is when running these tests. If you have any questions or want me to run other tests or modified ones, I can do that. Alex. -- 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.
