Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
High, I just found your package and wanted to contribute to it to make it even faster. I only did two things:
?.) when possible to reduce bundle sizeI don't know if it's okay to suggest using optional chaining, because you haven't specified a minimum required nodejs engine version in your
package.json. Optional chaining has been introduced in NodeJS 14 which came out 5 years ago. I think, it's okay to support it, because supporting anything below that would be unreasonable.Why is it important to outsource array lengths into a variable?
When accessing an object property like
object.property, the underlying JS engine (NodeJS uses v8), does a quick memory lookup into the heap to get the value of said property. This can decrease performance by quite a bit depending on the number of of object property accesses performed. Since a loop head checks the end condition on every iteration, it will do as many memory lookups ofarray.lengthas there are iterations. Additionally, I found a loop end condition of< array.length - 1and this will always recalculate the array length + doing a memory lookup.Other benefits of outsourcing object properties to variables.
The other main benefit of outsourcing properties to local variables is the reduction of the bundle size. Unlike other languages, JS is interpreted and can't be converted to bytecode. Many bundlers, most of them today are
esbuildbased, have no option to mangle and minify object property names. That means, if I have a propertyobject.superDuperMegaLongDescriptiveParagraphOfAnAwesomePropertyName, it will retain the name, bloating the bundle and output size of apps. While outsourcing is amazing to reduce bundle size, there is always the caveat of extra variables having to be cleaned up via the GC, so there has to be a balance.My recommendation for the future of this project would be to slightly reduce of calling properties through
this.and rather using local variables to further reduce the bundle size. Currently, it sits at a quite reasonable bundle size of 5.1KB as seen on bundlephobia, but I'm sure it can get a bit smaller.