Use flat for .ty serialization #1514
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This switches the serialization and deserialization format for our .ty files to use the flat library. Flat is one of the fastest serialization formats out there and it does indeed provide a speedup for Acton as well. Unfortunately, I started this work based on a vague memory I had of having seen that reading the .ty files took up a significant portion of total compilation time, in particular when a lot of files are just cached / up to date... and so I set out to speed it up. After having implemented flat, I see that I misremembered. Reading .ty files is actually very fast, the largest one I have takes 4ms. Using flat we cut that in half, down to 2ms. If I turn off zlib compression we can get it down to 1ms but at the expense of quite a lot larger files (like 4-5x). The files are about 30% larger with flat than before, but since we're on KB or tens of KB level here, that's not much of a deal. A 100% increase in speed is worth slightly larger files on disk. If we want ever more sp33d, we can consider removing zlib.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This switches the serialization and deserialization format for our .ty files to use the flat library. Flat is one of the fastest serialization formats out there and it does indeed provide a speedup for Acton as well.
Unfortunately, I started this work based on a vague memory I had of having seen that reading the .ty files took up a significant portion of total compilation time, in particular when a lot of files are just cached / up to date... and so I set out to speed it up. After having implemented flat, I see that I misremembered. Reading .ty files is actually very fast, the largest one I have takes 4ms. Using flat we cut that in half, down to 2ms. If I turn off zlib compression we can get it down to 1ms but at the expense of quite a lot larger files (like 4-5x).
The files are about 30% larger with flat than before, but since we're on KB or tens of KB level here, that's not much of a deal. A 100% increase in speed is worth slightly larger files on disk. If we want ever more sp33d, we can consider removing zlib.
I'm not sure we should switch to flat. 2x speedup is nice but since reading .ty files is such a small portion of total time, it's almost negligible. I can't tell if this makes our code base harder to maintain or whatnot, so I'll just leave it here for now. There's a notice in the flat readme or docs that compilation might be a fair bit slower with flat.