Once we realized this, we were able to speed things up with a cache by using the whole formatting string style='color: rgba(109, 109, 109, 1.000000) font: 20px \"Helvetica\" text-align: left -cocoa-font-postscriptname: \"Helvetica\" ' as the key for our text formatting cache. Everything else describes the formatting of the node - which is exactly the same for many other nodes in the document. The text itself, which is unique for this node, is "What will make this week a success?". While parsing the HTML description is slow and expensive, in a typical MindNode document many nodes look the same. This conversion is rather costly, so we looked into ways to speed it up.Ī node's title, converted by Ashton, can look like this: It can convert between an NSAttributedString, the object that is used to represent rich text in iOS and macOS, and an HTML representation of the same text. So you need to make sure to correctly invalidate your cache, or you'll be served wrong results.Īshton is our open source solution to convert between rich text and HTML and it's used heavily during saving and opening of documents. Whenever you cache a result it increases your memory consumption. Caches can dramatically improve the performance of many tasks, but they come with their own problems. Instead of computing a result every time we need it, we can cache the result and instantly return it on subsequent requests. In its essence, using caches is another way of being lazy. There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.Ī cache stores (usually expensive-to-compute) data, so that future requests can be served faster. By reducing KVO, providing a batch API and deferring work to a later point, we were able to speed up many operations like dragging around nodes on the canvas. This is exactly the approach that we took in many places lately. It would be much more efficient to first change the color of all nodes and then redraw the canvas only once. ![]() If we now redraw the canvas on every change, this is a lot of redundant work. But what if we change the color of many nodes at the same time, like for example when we apply a new theme? The way KVO works is that we get notified about the color-change of every node in our document, potentially hundreds or thousands. Whenever, for example, you change the color of a node in the inspector, the canvas gets notified of this change and knows that it needs to redraw the node with the new color - exactly what we want. KVO is a technology that allows us to observe the amount of fuel of our car, and get notified when it changes. Whenever the amount of fuel of our car drops below a certain threshold, we would want to know. An object car can have properties like color, amount of fuel and max speed and behaviors like accelerate() and break(). These objects can have certain properties and defined behavior, just like real objects. Speaking in simplified terms, in Object-oriented Programming we try to mimic real-world objects. Key-value observing, or KVO, provides a mechanism that allows objects to be notified of changes to specific properties of other objects. One common example of potentially unexpected side effects can be seen when using Key-value observing. At this size, it can become hard to reason about the code, especially if functions have side effects. While this may sound trivial, it's far from trivial in big and complex software with ten thousand lines of code or more. So being lazy is a good thing - the goal should be to only compute what is actually needed. Whenever a result is computed, which isn't actually needed at this point, unnecessary work is done that slows down the device. Funnily enough, it can be one of the most effective solutions to performance problems. Batch Processing & Deferringīeing lazy might not be a trait, that you'd attribute to fast and snappy software. Let's take a look at the most common problems and some ways to solve them. While issues might be complex and very diverse, the root source of many performance problems falls into one of a few buckets. ![]() Finding the fixes for performance issues can sometimes feel like the famous search for the needle in the haystack. In fact, performance tuning is a common task for many software engineers - and it can be equally frustrating as well as very satisfying. ![]() There are many factors that influence both the measurable, as well as the perceived performance of the software we all use and love.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |