* During unit tests, does extra verification on text based overlays (#59553)
This makes it so during unit tests, adding a text based overlay to something will runtime if the icon does not have an icon state matching that text. I would do this during normal compiles as well but getting the icon states from an icon is surprisingly expensive.
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@ users.noreply.github.com>
* During unit tests, does extra verification on text based overlays
Co-authored-by: Emmett Gaines <ninjanomnom@gmail.com>
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@ users.noreply.github.com>
* Removes CHECK_TICK from overlays, following the same theory as instant explosions. (#58382)
as we learned with instant explosions, sleeping needlessly between appearance changes results in a heavier sendmaps load, let's see how this performs
* Removes CHECK_TICK from overlays, following the same theory as instant explosions.
Co-authored-by: Iamgoofball <iamgoofball@gmail.com>
* Fix overlay subsystem holding on to excessive amounts of icons. (#58378)
* Fix overlay subsystem holding on to excessive amounts of icons.
The use of the icon file reference should be ok because they aren't ref counted anyways,
* Rename icon
* Makes the shit actually work
* Removes caching all together.
* fix compile errors
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Fix overlay subsystem holding on to excessive amounts of icons.
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* make overlay lists not persist when empty (#53787)
* make overlay lists not persist when empty
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
Robustin says:
The very heart of our overlay code, a single line that basically boiled
down to overlays = new_overlays, was the cause of so much overlay lag.
Human overlay code was by far the biggest culprit. Most objects have 0-2
overlays but humans are marching around with 20+ most of the time and
the current system was spending a LOT of effort comparing 20+ image with
20+ other images and then apparently rendering them all anyway. Human
overlays are at least 10x the cost of any other overlay process and on a
busy server the overlay compiling was 2x the cost of any other system.
I compared the cost of overlay changes by picking up/dropping a PDA in
the dorms 250 times, with a 50% chance to use our current overlay
compiler and a 50% chance to use a "direct addition/removal (+=, -=)
approach:
CURRENT 1120ms 133 (avg:8.4210529327392578)
SCRAPS 6ms 112 (avg:0.0535714291036129)
Now this PR makes our whole overlay subsystem use that approach for
overlay compiling and the early results look incredible. The best part
is this is just the START of improvements. Humans benefits the most
because their icon system was already designed for small, incremental
overlay updates. By moving other code from "Cut everything, then put it
all back" to only updating the necessary overlays (cough, APC's), we can
see similar improvements.
oranges says:
I've picked up this PR because robustin vanished, but I do see the value
in the approach, only things I added were the checks for the overlay
list len changing
I also retabbed the entire file because I am a brainlet and did it
without thinking
* Overlay per-type cost logging.
Overlays will now log how long each type took to process.
Changed up how overlays was done to account for the fact its a queue and not a processor. (it was using almost none of the processing subsystem framework)
Made the overlay loop faster by making it not cut the list until the end.
Added a simple generic benchmark stat tracking system.
I don't know how much overhead this adds to overlays. i may put it behind testing or something, but i do want to test this on the serbers to get some stats.
* Removes flush() as it was creating race conditions
* Use ref
* text2file
* Atoms added as an overlay will have their pending overlays compiled before being converted to an appearance
