borc.decodeFirst is 800x slower than it needs to be

[atg]

I benchmarked borc against msgpack-lite and JSON for arrays of medium-sized integers (my intended use-case).

Encode performance is within the same order of magnitude, but decode performance is wild (10x100 iterations):

= Decoding Time (ms) =
msgp.decode      1.41
borc.decodeFirst 1227.33
json.parse       1.47

It turns out borc makes a new Decoder() (which does some kind of very heavy initialisation) on every call to borc.decodeFirst(). So perhaps cache the instance of Decoder instead of making a new one each time.

When using a shared decoder, performance is more reasonable (1000x100 iterations):

= Decoding Time (ms) =
msgp.decode      106.46637630462646
borc.decodeFirst 191.69837522506714
json.parse       147.855890750885

[dignifiedquire]

Yes, if you know you are doing a lot of decodes, the api is intended to not use the static methods, but rather manage your own instance.

[dignifiedquire]

So the real fix here, is to update the documentation, the caching of the instance should be the job of the user, as they will know much better what to do with hit.

[atg]

A bug is still a bug whether documented or not. ¯\(ツ)/¯

[dignifiedquire]

PRs welcome :)

…

On 23. Aug 2018, 18:28 +0200, Alex Gordon ***@***.***>, wrote: A bug is still a bug whether documented or not. ¯_(ツ)_/¯ — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.