## About The Pull Request
[Refactors fancy type
generation](https://github.com/tgstation/tgstation/commit/3f218ac7b714a87477d3bd96425df709c6e7fa27)
Ok so we have this proc that generates concatenated names for types so
admins have a nice list to sort through.
The trouble is this is done by, for each type, iterating all possible
replacements, and seeing which ones apply (with expensive string
operations)
A clean run of this applied to all datums takes about 3.5 seconds on my
pc.
This sucks.
Ok so can we do better. Well, yes, pretty easily.
Rather then, for each potential type, iterating all the options, let's
build a zebra typecache (a lookup list of type -> string to use), and
use that.
Then we can use a list of replacement -> the bit to tear out to figure
out what to remove.
This works quite well. It does mean that we're doing it based off the
type tree and not type paths, so if we didn't have a replacement for
like, mob, it'd look weird, but we don't have cases like that so it's
fine.
Or well we sorta did, didn't have anything for atom movables or areas,
but I fixed that so sall good.
Anyway, we only need to do this work once. It takes about 0.3 seconds on
my machine, so we can cache it.
Just this on its own would technically slow init, since we have a some
code that's running this proc off static, but we can just not, that's
fine (technically saves init time too since we don't have to burn 0.1
seconds on it anymore).
This brings the cost of generating this list for all datums from 3
seconds to 0.16, assuming we have the static pre generated.
We could in theory pre-generate just like, all the strings?
But I don't think the cached cost is high enough for that to be a real
problem. IDK open to other thoughts
Oh also I had to reorder the strings in that list, cause
zebra_typecacheof has reverse priority. s life
[Updates stat tracking macro to work at world
start](https://github.com/tgstation/tgstation/commit/1fbfb701a16e6df7170ee642bef66b16652281d3)
It for some reason doesn't actually get anything this early, but now at
least the logging would in theory function
## Why It's Good For The Game
Better response times for admins, faster code, more better
## About The Pull Request
We've got a few space related things that are busted, and shuttle
movement is slow.
I'd like to try to improve these things, if just a bit.
Long list of only tenuously related topics. Sorry for the shotgun blast
#### [Fixes lazyloaded stuff having bad
space](https://github.com/tgstation/tgstation/commit/d4de176a63f87d0f820e0cb610cd192750c897d6)
We need to handle area transferring in maploading code under niche
cases, and we also need to actually init reservation spaces we create.
It's also redundant and potentially dupe creating to do area lighting
handling in changeturf, because it gets touched in turf init anyway. Old
me is stupid.
#### [Adds some doc comments, yeets
ssmappping/transit](https://github.com/tgstation/tgstation/commit/269717145d70a4a73198791ca50253c708ee3ac1)
We had a reserved space for just shuttles to use, except it wasn't for
just shuttles.
So in theory if the space got clogged with other shit, the shuttles
could have nowhere to actually use.
It's better to just have the two groups share real estate. More sane
### The "Starlight is Slow" Block
#### [Starlight optimization part one (don't check config for each
individual turf you check for
activity)](https://github.com/tgstation/tgstation/commit/7312a314bef281c1b85a377cf2dcb647a2045050)
#### [Starlight optimization part two (infer
context)](https://github.com/tgstation/tgstation/commit/be94c422ed76aa3f07b43cad4d1dc6b6148f135f)
Starlight was causing each space turf to cause itself and its neighbor
to constantly recheck if they had starlight off changeturf.
The exact same effect can be had by taking advantage of some
pre-existing information, namely if the space turf is gaining or losing
a source of starlight.
Essentially, instead of telling a turf to check all adjacent turfs to
see if it's got starlight, we tell the turf if WE are a source of
starlight, or if we might be taking something away from it.
There's a bit of wasted cpu here but not much, if it's worth doing a
register signal pattern for clearing depends on the case we're working
with.
Being intelligent about this makes things much faster, something in the
neighborhood of 4 to 3 fold.
I've also made openspace's starlight work better, cause the old pattern
was a bit silly.
### Changeturf is Annoying (Microops)
#### [Micro ops changeturf and turf deletion a
bit](https://github.com/tgstation/tgstation/commit/386b3ab7fc2a820a9ffe3d2e39d78f96dc562d64)
Don't do work if the thing you're working on doesn't exist, don't check
every adjacent turf for firelocks on turf change (just have thefirelocks
manage that), don't check all atoms on the turf for decals on turf
change, similar.
Also moves visibility changes from camera code into changeturf, to avoid
unneeded work.
Needs some extra work to optimize the guts for this path but I can do
that!
#### [Micros camera vis
changes](https://github.com/tgstation/tgstation/commit/ebab69e9ea4adffd8787671f309f4ba27756c82e)
We should only update vis when our opacity changes.
In addition, we don't need all the camera handling fluff if we only want
to update our turf's static groups.
Also micros a camera net helper to be less crap for non multiz maps
#### [Micros some open space atmos cases, alongside avoiding a for(null)
in opacity
handling](https://github.com/tgstation/tgstation/commit/72ae07ba1db1fb1c4434a4cdaecc78ea6a2864fc)
#### [Ensures space_lit tiles never accidentially inherit lighting
objects](https://github.com/tgstation/tgstation/commit/a99ff2265a4d1b157849fb7485adee17a3250df5)
S dumb, and leads to space turfs having two sources of lighting, which
looks wrong.
This was invisible when their lighting was fullbright, but it sucks now.
### Misc Stuff
#### [Cleans up stat tracking a bit to avoid
collisions](https://github.com/tgstation/tgstation/commit/40fb8f21e20d5bd9ef2f989eb166e03b30d66b3d)
#### [Cleans up a turf helper to not be
stupid](https://github.com/tgstation/tgstation/commit/bf4ee6710026e6ca9922d0f1fa49020ebde8cd6f)
WHY ARE YOU USING THE RANGED TURF HELPER IF YOU GO ONE TILE
#### [Moves transit turf signal cleanup to destroy, I named this proc
wrong](https://github.com/tgstation/tgstation/commit/c85c2cfc86f3b2dd224cae6b12e2fc428846c30b)
I'm sorry @Time-Green
#### [Adds better transit caching to
shuttles](https://github.com/tgstation/tgstation/commit/35e85334c4f815da0cadd8172e9908267a01d334)
Adds a max reserved transit size to the shuttle subsystem, to keep
things in bounds.
In addition, adds a soft cap under which existing transit space will get
hold onto, to make repeated non escape/arrive shuttle movements faster
Hopefully this makes common shuttle moves less bad.
## Why It's Good For The Game
Speed
Adds some new procs relating to baseturfs that replaces some code that
reads and sets them directly. Moves them to their own file. **To
reviewers: Any proc in baseturfs.dm that is snake_case is mine, anything
else is just moved**.
Adds tests for the existing procs of baseturfs.
I'm going to be doing some optimizations to baseturfs that change the
actual representation of baseturfs, and so I'm prepping these to be
implementation agnostic.
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
## About The Pull Request
[Saves 0.2 seconds of init time. 50% of emissive
blockers](https://github.com/tgstation/tgstation/commit/8318b648f6d32844aacbfb4c309152cd45801f5c)
Emissive blockers are a decent expense during init, even these, which
are the ones that update outside of initialize.
I've inlined them, removed some redundant vars and checks, reduced the
arg count, and shifted some things around. This ends up saving 200ms, or
50% of its total cost.
I also shifted mutable_appearance about a bit. it's not a massive
saving, but it is technically faster
[Prevents a few redundant appearance_updates, saves 0.8 seconds of
init](https://github.com/tgstation/tgstation/commit/5475cd778b66b22b1e2c8d86b2c6d59fb84f219a)
Prequisit info: update_appearance is decently expensive
It's good then to only do it if we have a reason to, right?
Me and moth were shooting the shit about just general init time, and we
came up with the idea of tracking which update_appearances actually
"worked" and which didn't.
That bit comes later, let's enjoy the fruits of that work first
First, holograms were calling update_appearance on process, for almost
no reason.
I patched the one event they don't already "react" to, and then locked
it behind a change decection if.
good for live, doesn't impact init.
Next, decals. If you add a decal to something before it inits, it'll
react to the after successful init signal.
The trouble is the same atom could have its appearance updated from this
MORE then once, since decals can be stacked on tiles, and signal
unregisters don't work once the signal is sent.
So we add a flag to track if we've had this happen to us or not, so it
only happens once.
saves 80 ms
Power! lots of things call power_change on init, often more then once.
We'll update appearance for each of those calls, even if only one is an
actual change.
That's silly, better to track what sort of power we're using for our
appearance and go off that changing
This was taking about 300ms. Really stupid
Icon smoothing. After emissive blockers were added, any change to
something's icon smoothing would lead to an update_appearance call.
Nasty shit, specially cause of walls, which don't even use emissive
blockers.
Ok then, so we'll always update appearance for movables, and will allow
turfs that are interested to hook it manually.
Not many of those anyhow
This is slightly a dev ux thing, but it saves 600ms so I think it's
worth it. Rare case anyway
Telecomms:
telecomm machines were updating appearance on process. This is to cover
for them turning on/off on process.
Better then to just check if on actually changed.
This cost adds up midgame, doesn't impact init tho
Materials:
There's this update_appearance call in material on_apply. it doesn't do
anything.
The logs will lie to you and say it does, but it's just like reapplying
emissives. It doesn't need to exist
Saves like 50ms
Canisters:
Live thing, lots of time wasted updating appearance for no reason, lets
see if we change anything first yes?
[Uses defines to wrap update_appearance for
tracking](https://github.com/tgstation/tgstation/commit/4fa82e1c9d93577aadb3c743f17196331f62e67c)
[Undoes _update_appearance changes, instead reccomends 2 regexes to
use](https://github.com/tgstation/tgstation/commit/a8c8fec57a4e43d1fa636b5ac68459903faa9fc5)
I need file and line number for my tracking, so I need to override
update_appearance calls, and also preferably not require every override
of update_appearance to handle dummy file + line args.
So instead, I created a wrapper proc that checks to see if appearanaces
match (they're unique remember, the two of the same visual appearance
will be equivalent)
The trouble is I can't intercept JUST proc calls, or JUST function
definitions with defines. it needs to be both.
So I renamed the /update_appearance proc to /_update_appearance
this way I can capture old uses, and don't need to worry about merge/dev
brain skew
~~It does mean that all update_appearance proc definitions now look
weird tho.
My profiling is leaking into dev ux. I wish I had better templating.~~
**The above is no longer being pr'd**, it's instead just recommended via
a few regexes adjacent to the define.
Smelled wrong anyhow
[Adds a setter for panel_open, so I can update_appearance on
it](https://github.com/tgstation/tgstation/pull/71658/commits/cf1df8a69fc1a816391d085ee7419b14f9fe9167)
## Why It's Good For The Game
Speed
Adds a macro to the stat_tracking macros that lets you export
counts/costs into a JSON file, which is significantly easier to parse
with stuff like jq.
It is delayed because these macros are used to profile potentially
extremely hot functions, where we cannot afford to do I/O every time. It
is sent every second rather than waiting until all are done because it
can also be used to profile functions that are potentially called
constantly, forever.
Usual concerns about unused code being added do not apply as this entire
file is for profiling macros that are only ever used at time of
profiling, and are never ever merged to master.
About The Pull Request
Micros lighting objects, and their creation
We save a good bit of time by not walking space turfs adjacent to new objects.
We also save some time with micros in the actual underlay update logic.
I swear dude we spend like 0.8 seconds of init applying the underlay. I want threaded maptick already
Micros lighting sources, and corner creation
A: Corners were being passed just A turf, and then expected to generatecorners based on that. This is pointless.
It is better to instead pass in the coords of the bottom left turf, and then build in a circle. This saves like 0.3 seconds
B: We use so many damn datum vars in corner application that we just do not need to.
This resolves that, since it pissed me off. It's pointless. Lets cache em instead
There's some misc datum var caching going on here too. Lemme see...
Oh and a bit of shortcutting for a for loop, since it was a tad expensive on its own.
Also I removed the turfs list, because it does fucking nothing. Why is this still here.
All my little optimizations save about 1 second of init I think
Not great, but not bad, and plus actual lighting work is faster now too
Why It's Good For The Game
Speed
* Removes overlay queuing, saves 6/7 seconds of initialize. Lightly modifies stat tracking macros
So we have this overlay queuing system right? It's build with the assumption
that the "add to overlay list" operation is real expensive, and is
thus useful to queue removals or additions.
It turns out that it just isn't, at least during init. In my testing the
operation of queuing took LONGER then the actual overlay add/remove did.
That's ignoring the cost of the subsystem's work.
I've also modified part of the stat tracking macro, since it took a good
bit of cpu time, and didn't seem to well, do anything. So far as I can
tell it always evaluates to 1
* 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
LemonInTheDark