You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So as proposed in this comment, with a fairly trivial refactoring we can change a lot of internal cases where we:
construct an array of chars
.join('') the array
proceed to use .charAt() or .charCodeAt() on the resulting string
.. to leave out the middle step entirely, and replace .charAt() calls with array indexing. For cases where we use .charCodeAt(), what we have to do is replace resultString.charCodeAt(i) with resultArray[i].charCodeAt() - not entirely sure which is faster, but either way it saves the creation of a string. That in itself might save us enough performance to make it worth it, and if we're compressing lots of large data that could matter in memory overhead too.
There might also be a few use-cases in the wild where it's more practical for people to have a returned array of chars instead of a single string, so it could also be a useful (fully backwards compatible) addition to the API.
Like I said, I'm on sick leave at home and currently bored, so I'm going to work on this, both in the lz-string.js and base64-string.js implementations, and push a PR later. Then I leave it up to you to decide if you like the changes!
The text was updated successfully, but these errors were encountered:
So as proposed in this comment, with a fairly trivial refactoring we can change a lot of internal cases where we:
.join('')
the array.charAt()
or.charCodeAt()
on the resulting string.. to leave out the middle step entirely, and replace
.charAt()
calls with array indexing. For cases where we use.charCodeAt()
, what we have to do is replaceresultString.charCodeAt(i)
withresultArray[i].charCodeAt()
- not entirely sure which is faster, but either way it saves the creation of a string. That in itself might save us enough performance to make it worth it, and if we're compressing lots of large data that could matter in memory overhead too.There might also be a few use-cases in the wild where it's more practical for people to have a returned array of chars instead of a single string, so it could also be a useful (fully backwards compatible) addition to the API.
Like I said, I'm on sick leave at home and currently bored, so I'm going to work on this, both in the
lz-string.js
andbase64-string.js
implementations, and push a PR later. Then I leave it up to you to decide if you like the changes!The text was updated successfully, but these errors were encountered: