-
Notifications
You must be signed in to change notification settings - Fork 569
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
LZ4 compared to LZ-string ? #142
Comments
LZ-String is specifically tailored to compress a string into another string, making the best use of the UTF-16 encoding. If you can store other type of data (uint8array, etc.) then it makes sense to use a library that will return this kind of data. LZ4 should provide the same compression level but should be much faster. |
My question is if you plan to release the 15bit character encoding as a separate project? As you noted on your page some browsers might have problems with arbitrary 16bit characters shoved into localStorage. A more general solution would be welcome to allow any binary data to be efficiently stored into such places with your excellent 15bit encoding. This would work well with other compression outputs and even binary images. Yes there are other solutions for binary data (like IndexDB) but I found that some browsers (e.g. Safari) have way better performance when reading from localStorage during the initial rendering of the page. So for first paint critical resources this would be very helpful. |
I found a library for it |
There are some nice benchmark for LZ4 here but I'm not a pro of compression.
I'm looking for a way to store objects for a web extension and since lz-string was primary developed for this, I'm tempted to use it, but I was wondering if there was a good point in using lz4 (wasm)?
The text was updated successfully, but these errors were encountered: