Right then why would you ever even use this library instead of a typed byte array? ASM.JS isn't needed for typed arrays, besides its only supported on FF.
That's a definite possibility. We went with base-94 because it avoids UTF-8 overhead in situations where the browser will treat your data as a string (e.g. no typed-array support). We also wanted copy/paste to work, and for Flotsam data to be embeddable into JSON with minimal expansion.
No, this encoding uses a bitwise encoding for each float, so they are fixed at 10 characters each and encoded with constant speed (except possibly for subnormal numbers, which I've heard are slower in some environments).
This is a problem that only "walled garden" languages like Java and JavaScript would ever even have in the first place. If you're not trapped in a gilded cage, you just print raw bytes directly to a socket and then read data back the same way. The only concern is byte ordering, which is easy.
Regarding this specific approach, "only 20% overhead" sounds pretty good, but base 64 encoding has "only 33% overhead", is completely general, and likely already has faster implementations than this.
Hah, I did almost the same thing recently!
Precision and rounding was not that important though so i just went with log2 to get the exponent, normalize and cast to int to get the mantissa.
Then I realized I could do it properly by just using a typed array :)
11 comments
[ 0.19 ms ] story [ 31.5 ms ] threadI had good performance gains versus JSON as evidenced by this popular JSPref:
http://jsperf.com/json-vs-base64
Regarding this specific approach, "only 20% overhead" sounds pretty good, but base 64 encoding has "only 33% overhead", is completely general, and likely already has faster implementations than this.