lz-string for Haxe

[markknol]

Just wanted to let you know I've ported lz-string to Haxe
Find the source here https://github.com/markknol/hx-lzstring

(This allows Haxe developers to use the library in all of Haxe's targets; JavaScript, PHP, C++, Lua, Python, Java, C# and its own interpreter / VM's)

[JobLeonard]

Nice! I'm also curious what the JavaScript version of compiled Haxe lookes like

[markknol]

It will look like this
https://gist.github.com/markknol/1012a7ad76d9cffd363d7c29656e4105

Some notes to understand where you are looking at:

• Including the test it is 18kb (Minified this will be ~7kb. gzipped thats ~3kb)
• As comparison, the original lz-string.js in this repo is 16kb
• Haxe always bundles all code into one file
• In my version I changed the dictionaries for a typed Map, which makes it type safe and work on all Haxe targets, but it adds some standard library code.
• Haxe has a static analyzer that does dead code elimination, so unused functions are stripped. In my example I only use compressFromBase64 and decompressFromBase64, you won't see the compressFromUint8 function for example.
• I added both ES5 and ES6 ouput

[JobLeonard]

Nice, thanks for the explanation! Surprised Haxe doesn't optimize stuff like this away though: dictionary_h[0] = "" + 0; dictionary_h[1] = "" + 1; dictionary_h[2] = "" + 2;

…

On Fri, Apr 12, 2019, 10:46 Mark Knol ***@***.***> wrote: It will look like this https://gist.github.com/markknol/1012a7ad76d9cffd363d7c29656e4105 Some notes to understand where you are looking at: - Including the test it is 18kb (Minified this will be ~7kb. gzipped thats ~3kb) - As comparison, the original lz-string.js in this repo is 16kb - Haxe always bundles all code into one file - In my version I changed the dictionaries for a typed Map, which work on all targets, but add some standard library code. - Haxe has a static analyzer that does dead code elimination, so unused functions are stripped. In my example I only use compressFromBase64 and decompressFromBase64, you won't see the compressFromUint8 function for example. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#133 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAP3AG5L3jTxrG3Ul424tl3JZl8OQPbgks5vgEfbgaJpZM4cpcH-> .

[markknol]

What do you mean with optimize away? It converts ints to string.

This case is actually already quite nice. it unrolls a loop, this is the code I wrote

		for (i in 0...3) {
			dictionary[i] = '$i';
		}

https://github.com/markknol/hx-lzstring/blob/master/src/lzstring/LZString.hx#L337-L339

[JobLeonard]

Well, since these are constants it could have done further strength reduction to:

    var dictionary_h = { };
    /* ... */
    dictionary_h[0] = "0";
    dictionary_h[1] = "1";
    dictionary_h[2] = "2";

And since the full context of that bit of code is:

    var dictionary_h = { };
    /* ... */
    dictionary_h[0] = "" + 0;
    dictionary_h[1] = "" + 1;
    dictionary_h[2] = "" + 2;

Theoretically it could even have reduced it further to:

    var dictionary_h = { 0: 0, 1: 1, 2: 2 };

The last optimization would probably be a difficult pattern for the average compiler to detect, but the first one seems pretty straightforward.

[ncannasse]

Yes we don't optimize string concat in order to limit the number of strings in the string pool on some targets. We could optimize for JS.