Cache image list markers #303
Conversation
| @@ -410,7 +427,7 @@ class LayoutManager: NSLayoutManager { | |||
| let attributes = lineNumberAttributes(lineNumberFormatting: lineNumberFormatting) | |||
| let text = NSAttributedString(string: "\(lineNumber)", attributes: attributes) | |||
| let markerSize = text.boundingRect(with: .zero, options: [], context: nil).integral.size | |||
| var markerRect = self.rectForLineNumbers(markerSize: markerSize, rect: rect, width: gutterWidth) | |||
| let markerRect = self.rectForLineNumbers(markerSize: markerSize, rect: rect, width: gutterWidth) | |||
There was a problem hiding this comment.
There was a warning for this variable not being changed after assignment, so I changed it to be a let constant
| let sizeCache = imagecache[image, default: .init()] | ||
| imagecache.updateValue(sizeCache, forKey: image) | ||
|
|
||
| let key = size.debugDescription as NSString |
There was a problem hiding this comment.
I'm open to suggestion on how to further optimize the keying strategy. With this change, the most expensive operation becomes generating the string description for the size (the whole 4ms in the screenshot above). Interpolating the image and size in a single string was coming up at 11ms, which is still better than the original 650ms, but I ended choosing the fastest version.
There was a problem hiding this comment.
this seems pretty good @erudel. We can evaluate if we can use a better strategy than this for generating the key but this in itself seems like a substantial improvement. Thank you for taking this up.
Problem: when an editor contains many list items that are represented by the same image marker, there is a substantial amount in the layout pass spent resizing the image to the given size.
Solution: since the markers and sizes are the same for list items, we can cache the resized image and reuse it for successive calls. In some cases the number of calls to resize images went from ~7700 to just 4.
The implementation uses a Dictionary to store a cache for each image, and the cache is keyed by the size. I tried creating a cache with a single key derived from the image and size, however the string interpolation turned out to be more expensive than this approach.
I profiled the rendering before/after the change and here are the results:
Before:
After:
