Skip to content

Rewrite of wrappers functions to use the compression method directly
Compare
Choose a tag to compare
@pieroxy pieroxy released this 19 Feb 21:02
· 147 commits to master since this release
1.4.0-beta
0891e82

This avoids calling compress and then re-encoding the results in UTF-16, base64 or URIEncoded string.

As a result:

  • The compress method is slightly slower.
  • The compressToUTF16, compressToBase64 and compressToEncodedURIComponent are slightly faster (in theory).
  • Binary compatibility for decompression is still there. This means any String compressed with an old version of the library can be decompressed by this version, and any String compressed by version 1.4.0 can be decompressed by an older version.
  • Binary compatibility for compression is not guaranteed, meaning the output from this version may be different than the output produced by an older version. This is trailing characters that are useless that are now omitted.

The jsperf (Please take them to add more results and help me prove my theory):

http://jsperf.com/lzstring-1-3-8-vs-1-4-0-forcompress/2
http://jsperf.com/lzstring-1-3-8-vs-1-4-0-for-utf16
http://jsperf.com/lzstring-1-3-8-vs-1-4-0-for-base64
http://jsperf.com/lzstring-1-3-8-vs-1-4-0-for-uri-component

NOTE: Releasing this as the performaces seems good except for base64 and uri component on IE. Those don(t take too big of a hit and are designed to send the compressed data to the network (usually internet which is orders of magnitude slower than the compression algo). So I'm going with it.

Assets 2
Loading