Open cakoose opened 5 years ago
Hello, thanks for this, as you say this module is fairly clear in the use case being Buffer-to-Buffer (de)coding.
If the benchmarks were to include test cases that either consume or respond with Strings then perhaps this module should provide new functions such as encodeAsString
and decodeFromString
to match if that's an API people would expect to be available.
In addition, if you're aware of a native Buffer method in Node to perform base64 encoding/decoding without the use of intermediate Strings then that would make a better benchmark test.
I do think that most people who come across this package will mistakenly think that it does the exact same thing as Buffer.from
. That's definitely what I did when I came across it a few weeks ago.
And separately, I think it's generally valuable to give people a rough idea of what the Buffer-to-string conversion overhead is. Might make them rethink some of the things they're doing elsewhere :-)
Maybe separate charts for encode and decode will keep things readable?
Updated the pull request with a bunch of changes.
Not sure if these changes align with your preferences. Lemme know if you'd like me to do things differently. Or if it's easier for you, feel free to rework everything yourself -- authorship on the final commit is not important to me.
I was surprised when I saw the extra string conversion in the benchmark code. I think it may surprise others as well.
Though people who care about performance will probably be using Buffers as input and output, I think it's worth making it clearer what the benchmark is actually measuring.
It also helps explain why the performance difference is so large.