But in spite of setbacks--including spending Wednesday in a Benadryl coma--I've managed to wrap up, for now, the optimization work that began last week. Dream Seeker should have improved performance in several categories.
- Another path for optimization was found in the view code, which also means the server side gets a slight benefit as well.
- The gathering of view matrix parameters (opacity, etc.) has been sped up slightly, on the client only, by combining all atoms on a tile into the same routine and therefore avoiding redundant lookups.
- Areas now cache their icon list for the duration of a tick; since the same area is usually called on to produce icons a few hundred times or more every tick, this is a non-trivial time savings.
- Overall atom-to-icons production time has been trimmed as much as possible--which wasn't very much, but still there were a few minor improvements.
- The tile-to-atom-list routine was improved by shortcutting a lot of redundant logic.
- Sorting time for the master icon list has been cut in half. This isn't a big deal for small views, but for wider views it makes a bit of difference and in isometric--which currently sorts twice--it's huge.
I have identified some targets for future optimizations, but it's time to put the mini-project to bed and move on to other items. In the future, this is what I'd like to target:
- Transforms and color matrices use up a lot of memory in at least one of the icon formats, and also use a lot of extra logic in some others. It would be nice to switch to using shared items that just have a reference ID, which can later be garbage-collected as needed. This would generally save time as well as memory.
- Items marked "interesting" by the server for the possibility of spreading out onto other tiles may not actually be visible within the map bounds. Since the client doesn't know this in advance, it still does atom-to-icons generation that ought to be skipped. Setting up some kind of crude visual bounds system on the client, like the server has already, would be a good idea.
- Icons very much need to mark their physical positions--the webclient does this already--for the sake of future topological sort algorithms.
- A lot of logic that handles changes of icon position due to client.dir should be completely changed to avoid even bothering with said logic until the main icon-filling loop is finished, since most projects never touch client.dir.
But for now, time to move on back to hopefully getting the webclient in shape and also adding that client profiling that's been much requested. The groundwork for said profiling is already in place, in that there are places in the code where performance on these various rendering sub-tasks can be measured, so it's just a matter of adding to the frontend.
Big thanks to everyone who's become a BYOND Member or donated, and those who've opted to show their support on Patreon. I know some power users in particular have been dying for a boost to performance, so I hope this latest round of optimizations works out well for you guys.