Sometimes… Performance Tuning is Just Exercise
This morning, I was taking another crack at increasing the performance of the graphing in Potentials, as my initial tests of just draw red seemed to show that I could cut a significant amount of time off the drawing, if I didn't have to allocate all those NSColor objects. Seemed like a reasonable thing to try, and after all... performance tuning can be fun.
So it's not like the CGColor or NSColor would allow me to directly access the values of red, green, and blue - so I had to move them from the NSColor instance into a simple array of CGFloat values. No big deal - now I'm passing around a simple, fixed-size array that is easily indexed, and because I can make them on the stack, there's no way these are leaking.
Then I needed to peel back the existing methods on ResultsView and make it so that they allowed for passing in, and returning, arrays of CGFloat values. Again, this is a simple refactoring, as I could then simply use these new methods within the existing methods, and I didn't loose any capabilities of using NSColor arguments. Still good.
Finally, I was then able to update the drawing method and have it convert the input colors to linear space, and arrays of CGFloat values, and then run the same processing on these arrays of CGFloats, and we had what we'd hoped for.
Almost.
What I saw was that there was 2 msec difference - out of 17+ msec - that this changed. Nothing. So I backed out the changes, and realized that I had a new respect for the macOS developers - they have really tuned this machine to make the AppKit/Foundation way of doing things about as fast as humanly possible - and the difference with just plotting red was that of a single color versus a range. This was the case all along, and I was mistakenly thinking that I was seeing some effect that wasn't really there.
So it's not faster... but I am wiser about the inner workings of macOS and drawing, and I'll be sure to remember this in the future. 🙂