string_decoder: optimize write()#1209
Conversation
By limiting property getting/setting to only where they are absolutely necessary, we can achieve greater performance especially with small utf8 inputs and any size base64 inputs.
|
nice, I like those utf8 numbers, any idea how much property getting is impacting this? LGTM |
|
I made these changes awhile ago so I can't recall for sure, but this patch is almost entirely made up of changes to avoid property lookups, so I would say that it is impacting things the most (especially in the loop in |
|
/cc @iojs/collaborators |
|
LGTM |
|
This should be implemented in C, we will need utf8 decoder in the future for |
|
@petkaantonov Why? Is V8 dropping their UTF-8 decoder soon? |
There was a problem hiding this comment.
I wonder if V8 will unroll the subsequent loop (or if there's value in doing so ourselves.)
There was a problem hiding this comment.
You mean for the i = 3 case? I didn't try that since I figured people would frown about code duplication between the i = 3 and i = buflen cases. I also did not see what kind performance difference it would make though.
|
This LGTM.
We'll still have to support this module if we move to a C decoder, so making it faster is probably worthwhile. |
By limiting property getting/setting to only where they are absolutely necessary, we can achieve greater performance especially with small utf8 inputs and any size base64 inputs. PR-URL: #1209 Reviewed-By: Rod Vagg <[email protected]> Reviewed-By: Nicu Micleușanu <[email protected]> Reviewed-By: Chris Dickinson <[email protected]>
|
Landed in 8a94581. |
By limiting property getting/setting to only where they are
absolutely necessary, we can achieve greater performance
especially with small utf8 inputs and any size base64 inputs.
ascii/binary are unaffected.
Example results for utf8 and base64 from the included benchmark: