-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize Player
.
#470
Comments
A binary format means no scanning and then reading, just reading. |
Two things that will make To stand up in a shootout, we're going to need to turn off checksums and use a binary parser. These can be switches, a switch to turn the checksums on, and a switch to use the UTF-8 format, so that, by default we have no checksum and use a binary format. |
No improvement from moving |
JavaScript DJB is faster than `crypto` SHA1. The binary frame is faster than the UTF8 frame, of course. There is still room for improvement in read performance by calling `splice` directly on the items, or at least removing the invocation of `reduce` in `Page.splice`. insert: 61, gather: 36 See #470.
Use a `for` loop instead. It is faster. Especially considering that the list of items is often a list of one. insert: 60, gather: 34 See #470.
Player
has three potential bottlenecks; checksum generation, deserialization and splicing. Checksum generation and testing is something that we do that others might not do, so we are going to pay a price for those checksums in the shootouts. Checksums require slices. Maybe it is faster if you use a JavaScript checksum modified to work with buffers and ranges. If it comes down to all benchmarks all the time, then we're going to want to turn them off inLocket
, or else wait until they save someone's bacon.Deserialization might be improved by using a binary file format. Maybe it is enough to can for the end of the header array explicitly. Maybe it is important to go binary. You could create a translator that would read a binary file format and emit your pretty text format. Binary means you could use a Packet compiler and have a best-foot forward reader. It would be easier to checksum without having to read into buffers.
You might want to consider making record serialization pluggable.
I'm concerned that the Magazine lookup on each splice is costing too much. The
Cartridge
could be stored in the page, so adjusting heft could be done without the lookup.Reading the buffer from file seems to happen quickly enough and there is little that I can do to make Node.js load a file faster. All performance must be squeezed from the synchronous buffer reading loop.
The text was updated successfully, but these errors were encountered: