GeezerVison is showing github.com — Reuse Encoder/Decoder instance? · Issue #172 · msgpack/msgpack-javascript
Reuse Encoder/Decoder instance? #172
Description
The readme says that encoding is 20% faster when reusing an Encoder instance. If that's the case, is there any reason not to just memoize them in encode (or at least reuse a default instance when no options are set)?
Activity
gfx commented on Apr 30, 2021
That's a good question. There's an example in test/reuse-instances.test.ts, but they only accepts positional parameters right now, so I might change their interfaces to accept named parameters just like as encode({...}) and decode({...}).
buu700 commented on Apr 30, 2021
Oh, just to clarify, I wasn't asking about the documentation. I was suggesting an optimization to the default encode and decode functions / wondering whether there was a non-obvious reason that that hadn't been done.
gfx commented on Apr 30, 2021
Ah, sorry! Misunderstood.
There're some reasons that we cannot memorize them:
instance.*Async() are not async-await safe (or not thread-safe)- the instance has lots of configuration parameters so it's difficult to memoize
buu700 commented on Apr 30, 2021
Got it, that makes sense. If memoizing isn't an option, what about just pre-initializing a default instance that gets used when options is undefined? That would at least cover the most common case (I'm assuming).
gfx commented on Apr 30, 2021
Sounds good. Will try it.
buu700 commented on Apr 30, 2021
Nice, thanks! I'd be happy to submit a PR if that would be helpful.
Metadata
Metadata
Development
No branches or pull requestsIssue actions