At Wed, 30 Jan 2019 16:31:52 -0800 (PST), Alex Harsanyi wrote: > On Wednesday, January 30, 2019 at 10:53:21 PM UTC+8, Matthew Flatt wrote: > > > > * 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?
(2) > 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? I don't think you should have to change your program, for now. Instead, I think need to better understand how different layers of the language implementation contribute to the code size. Maybe we find that everything's really as it should be, or maybe not. > 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? That's pretty much the case, as far as I know. > Is there some documentation on how to measure the amount of code used by > contracts (the 15% value you mention above)? No. Sam set up a branch of TR that skipped contract generation, and I compared ".zo" sizes using that branch versus the normal one. > 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. Although there are costs to TR in compile time and load time, especially in a program that also has untyped components, I generally would not recommend moving away from 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. > > I am not sure what "significant" means, but the tests don't read and > write a large amount of data: I was probably wrong about this, because I didn't look before into "fit-file.rkt". I see now that the data-parsing code there doesn't use Racket's port API, so the I/O layer in Racket CS is probably not the issue --- at least not in the way that I thought. > I would be happy to help you identify where the performance degradation > between Racket 7.1 and CS is when running these tests. Small examples that illustrate slowness in a specific subsystem are always helpful. I can't always make the subsystem go faster right away, but sometimes. -- 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.
