So I was looking at perf for https://github.com/microsoft/windows-rs/issues/420#issuecomment-765549226 and one of the issues is the search index is almost 60 MB (!!). There's an issue open for fix it (for almost 5 years now): https://github.com/rust-lang/rust/issues/31387. Some of the suggestions were:
I think "use a binary format" is the simplest, and should also have a big effect on the file size and load time. @GuillaumeGomez what do you think? Do you have suggestions for a format?
Your guess is as good as mine. However, please keep in mind that we need to be able to manipulate it easily to add or update a crate in the search index.
Would a compressed json (using gz or something) be terrible?
hmm, I'm not sure if that works without a web server
doing all this locally makes it hard :/
I'm not sure if it's any more complicated than with a server that serves a .gz, but I'm not sure if js implementations of any inflate algo would be fast enough.
anyway, probably a bad idea :smile:
I would be interested in seeing numbers for gzip
are you interested in writing that up? :)
unfortunately I'm more interested in figuring out why the keccak benchmark borrow-checks 3300 times :frown:
To be perfectly honest: I think that if it's not something handled by the web-browser directly, the size will reduce, but the performance will drop too.
We can add a compressed JSON that we decompress in the browser, but that will very likely be horribly slow
our only viable options are the ones provided by the browsers' API
Take a look at my blog post I posted today to give you a little idea of the things I went through already ;)
but since I'm not a front-end engineer, it's very possible that I missed a way to do things better, which is why I'd be glad if someone came with someone I never heard of (it'd be really wonderful)
Last updated: Oct 21 2021 at 19:46 UTC