Optimize the base64.decode function. #185
Conversation
|
BTW, why you didn’t use base64 function from some npm library? |
|
At the time this lib was originally written, I'm not sure there was a good solution on npm. It was easy to implement it myself. The requirement of running on node, in browsers, and within Firefox is another consideration, but not a show stopper. |
| if (aChar in charToIntMap) { | ||
| return charToIntMap[aChar]; | ||
| exports.decode = function (charCode) { | ||
| var bigA = 65; // 'A' |
There was a problem hiding this comment.
Is the JIT clever enough not to reinitialize these variables on each call to decode? If not, these constants should be moved outside the function
|
Patch looks good to me. r+ It's a bit surprising that a property lookup is so much slower than a bunch of hardcoded if blocks. Intuitively, I'd expect table lookup to always win out over explicit branching (when not taking cache effects into account). In any case, I wonder if doing a lookup based on the character's charCode, rather than it's string representation, would be any faster. Array element lookup is supposed to be faster than object property lookup, so I guess it depends on what the JIT can optimize. I expect it won't be faster than the inline code you just wrote, but it might be worth looking into at some point. |
This function is incredibly hot while parsing mappings. By avoiding property gets and throwing errors in this function, we get about 2000 millisecond improvement on the mean time to parse our source map in bench.html.
Optimize the base64.decode function.
This function is incredibly hot while parsing mappings. By avoiding property
gets and throwing errors in this function, we get about 2000 millisecond
improvement on the mean time to parse our source map in
bench.html.r? @ejpbruel