I looked at various things on jsperf like
http://jsperf.com/json-bson-msgpack/2 and ran the benchmarks for
https://github.com/pgriess/node-msgpack on my machine.
David
On Mon, Aug 4, 2014 at 11:56 AM, Francis Avila wrote:
> I thought MessagePack js implementations were quite a bit slower than
>
I thought MessagePack js implementations were quite a bit slower than
4-5x. Do you know of any benchmarks? String encoding/decoding is
definitely big part of the slowdown, not disagreeing.
MessagePack doesn't even have a string type: I think it's only
convention that their raw type contains utf-8
On Mon, Aug 4, 2014 at 11:14 AM, Francis Avila wrote:
> The difference in performance between native and non-native string
> encoding (using the fastest js implementations I can manage to write,
> granted) is at most 2x to 3x, which is certainly an improvement but
> not enough to overcome the appr
The difference in performance between native and non-native string
encoding (using the fastest js implementations I can manage to write,
granted) is at most 2x to 3x, which is certainly an improvement but
not enough to overcome the approximately order-of-magnitude difference
in overall encoding and
I've looked closely at utf-8 encoders/decoders in JS vs TextEncoder, and I'm
not sure fast string encoding/decoding alone is going to bring us the kind of
speed improvements we need to make binary formats a clear win over JSON. (Some
of this might be because the ArrayBuffer implementations are
On Mon, Aug 4, 2014 at 10:51 AM, Francis Avila wrote:
> I've looked closely at utf-8 encoders/decoders in JS vs TextEncoder, and I'm
> not sure fast string encoding/decoding alone is going to bring us the kind of
> speed improvements we need to make binary formats a clear win over JSON.
> (Som
Peter,
Cool let us know if you pursue this and have any numbers to share. It
may be the tipping point for going for binary formats like
Fressian/MessagePack over JSON representations.
David
On Mon, Aug 4, 2014 at 10:26 AM, Peter Schuck wrote:
> That would definitely help, a large percentage of
That would definitely help, a large percentage of the conversion time is
manually converting strings to utf-8 bytes and back again. Thanks for
pointing that out.
Peter Schuck
On Sun, Aug 3, 2014 at 9:14 AM, David Nolen wrote:
> RE: writing/reading strings I wonder if this won't help
> https:/
RE: writing/reading strings I wonder if this won't help
https://plus.google.com/+AddyOsmani/posts/4GgX9CD6c1X?
David
On Sun, Aug 3, 2014 at 9:51 AM, Peter Schuck wrote:
> Fressian's caching strategy is very flexible and powerful but doesn't have a
> lot of documetnation. I view Fressian's cachi
Fressian's caching strategy is very flexible and powerful but doesn't have
a lot of documetnation. I view Fressian's caching as similar to memory
references for Clojure values. You can cache any value no matter how large
and once the value is cached referencing it again is only a few bytes.
Fress
I took "significant structural similarity" to primarily mean at least maps
with similar keys, which Transit caching will cover.
On Sat, Aug 2, 2014 at 1:49 PM, David Nolen wrote:
> In Transit, maps keys, symbols, keywords, and tagged value tags are
> subject to caching.
>
> Fressian's caching s
In Transit, maps keys, symbols, keywords, and tagged value tags are
subject to caching.
Fressian's caching strategy is far more flexible from what I
understand. That said transit-cljs is 20-30X faster than
cljs.reader/read-string on the benchmarks I've tried across various
browser and command line
I thought transit's caching only applied to map keys? Pretty unclear on
what Fressian's can do
On Sat, Aug 2, 2014 at 8:23 AM, Alex Miller wrote:
> Cool stuff Peter. It would be interesting to compare performance with
> transit-cljs https://github.com/cognitect/transit-cljs. Transit has the
> s
Cool stuff Peter. It would be interesting to compare performance with
transit-cljs https://github.com/cognitect/transit-cljs. Transit has the same
caching and extensibility benefits of Fressian but leverages the very fast
JavaScript parser capabilities built into the browser, so is likely faster
14 matches
Mail list logo
