Skip to content
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

Rewrite for smaller size and better speed. #1

Merged
merged 1 commit into from
Jul 11, 2018
Merged

Rewrite for smaller size and better speed. #1

merged 1 commit into from
Jul 11, 2018

Conversation

gloryknight
Copy link

Replace StringStream object with global variables. Optimize arrays generation. About 5% smaller minified file. About twice faster in compressing large files.
I would also suggest to create separate small files for encoding and decoding. In my case they are of sensational 665 and 659 bytes.

Replace StringStream object with global variables. Optimize arrays generation. About 5% smaller minified file. About twice faster in compressing large files.
@JobLeonard
Copy link
Owner

Twice as fast as old code, or as StringStream for large objects? In the latter case I'd like to see the jsperf benchmark for that one, that sounds spectacular! :)

(did you try with different kinds of data? The compressibility of the input has a huge impact on performance)

@JobLeonard
Copy link
Owner

So here's a quick set of benchmarks with various input sizes and types (badly compressible, very compressible, "perfectly" compressible, long and short. With and without minification). It's not immediately obvious which version is the fastest.

So the other main question then is:

  • is this significantly clearer, or less clear?
  • does it save a lot of space?

It's not much better or worse than before in terms of readability, and minified we go from 3259 to 3144 chars, so that's 115 characters, or bytes saved.

So I might as well accept the request.

https://run.perf.zone/view/LZString-variants-11-07-20182018-1531265786778

https://run.perf.zone/view/LZString-variants-11-07-20182018-random-string-of-1s-and-0s-1531265884701

https://run.perf.zone/view/LZString-variants-11-07-20182018-random-string-of-a-b-c-and-d-1531266188696

https://run.perf.zone/view/LZString-variants-11-07-20182018-random-string-of-1s-and-0s-1531266339448

https://run.perf.zone/view/LZString-variants-11-07-20182018-random-string-of-1s-and-0s-1531266407710

https://run.perf.zone/view/LZString-variants-11-07-20182018-perfectly-compressible-string-of-as-1531266529755

https://run.perf.zone/view/LZString-variants-11-07-20182018-perfectly-compressible-string-of-as-1531266709674

https://run.perf.zone/view/LZString-variants-11-07-20182018-short-perfectly-compressible-string-of-as-1531266872647

https://run.perf.zone/view/LZString-variants-11-07-20182018-short-string-of-random-1s-and-0s-1531266947712

https://run.perf.zone/view/LZString-variants-11-07-20182018-minified-long-string-of-random-1s-and-0s-1531267533062

@JobLeonard JobLeonard merged commit 98faded into JobLeonard:array-lookup Jul 11, 2018
@gloryknight gloryknight deleted the patch-2 branch July 11, 2018 08:56
@gloryknight
Copy link
Author

Thanks for accepting.
The performance looks good (in comparison with the version 1.4.4 any way). In order to be fair I think you should compare minified versions since this is what will be used in performance critical or productive applications any way (my comparison is based on minified versions with 250kB of real live JSON. Will upload it when I have time).
My suggestion: just release V2.0.0 and do optimizations in the following versions. People using it and will benefit from the speed improvements.
I like this project - keep it moving.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants