-
Notifications
You must be signed in to change notification settings - Fork 226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize NSString.NSRangeToByteRange(start:length:)
#122
Conversation
This is that I mentioned in #120. |
I think the performance issue that related to realm/SwiftLint#247 is almost resolved, and another performance issues that made SwiftLint slower than 0.4.0 are caused by rules. |
Today, I worried about that this PR would make leaks String instance. |
cache[location] = entry | ||
|
||
// keep largest 5 entry | ||
if cache.keys.count > 5 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it really necessary to evict cache entries? An Int/Int keypair is minuscule in memory compared to the rest of the strings we're working with.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now I tested again.
I confirmed that evicting cache does not affect performance. 👍
I'll remove that.
Thank you for reviews. |
I also found that using Should we avoid using this approach? |
NSString.NSRangeToByteRange(start:length:)
NSString.NSRangeToByteRange(start:length:)
It seems I need to using two workarounds for resolving memory leaks.
|
NSString.NSRangeToByteRange(start:length:)
NSString.NSRangeToByteRange(start:length:)
I added workarounds for memory leaks. |
Introduce `ByteOffsetCache` for calculating byte offset. By applying this, linting KeychainAccess by SwiftLint-0.5.1 is reduced from: ``` swiftlint 21.87s user 0.24s system 97% cpu 22.611 total ``` to: ``` swiftlint 16.62s user 0.24s system 97% cpu 17.362 total ``` On Instruments, `NSRangeToByteRange()` is reduced from 6579ms to 315ms on that test.
Rename `entry` to `byteOffsetIndexPair` Remove evicting `ByteOffsetIndexPair.cache`
There are two reasons for: 1. Avoid using associatedObject on NSTaggedPointerString (< 7 bytes) because that does not free associatedObject. 2. Using cache is overkill for short string. There is no verified reason for the threshold "50", but I
If string is `Swift.String`, holding that into `ByteOffsetCache` does not cause Circular reference, because Casting `String` to `NSString` makes new `NSString` instance. If string is native `NSString` instance, Circular reference happens on following: ``` self.utf8View = (string as String).utf8 ``` Because the reference to `NSString` is holded by every casted `String`, their Views and Indices.
9019d20
to
6656224
Compare
rebased to master |
Optimize `NSString.NSRangeToByteRange(start:length:)`
Awesome! Thanks for yet another solid contribution. |
😄 |
Introduce
ByteOffsetCache
for calculating byte offset.By applying this, linting KeychainAccess by SwiftLint-0.5.1 is reduced from:
to:
On Instruments,
NSRangeToByteRange()
is reduced from 6579ms:to 315ms:
on that test.