11 Commits

Author	SHA1	Message	Date
LemonInTheDark	74892ae7ec	Optimization pass focused on foam code (saves about 30% of cpu usage I think) (#76104) ... ## About The Pull Request Foam is crummy at high load rn, both because it runs on a low priority background subsystem, and because it wastes a bit of time. Let's reduce usage (while speeding up a bunch of other stuff too), and give it more cpu generally. [Optimizes reagent processing somewhat](d409bd4afc) Turns out most of the cost of foam is the reagents it carries, and the varying effects they have I'm doing my best here to optimize them without touching "user space" too much That means doing things like prechecking if we're gonna spawn on top of an existing decal (from glitter, flour, etc), and using that same proc to also avoid spawning on unacceptable turfs (I had to convert inheritance to a bitflag system to make this work, but I think that's ok since we want it imparative anyhow) It's actually nice for code quality too, since it lets me clean up code that was using raw locates and weird var pong. god I wish I had implied types man [Optimizes foam spreading in its most accursed aspect, reagent copying](5cc56a64ad) Holy shit reagent code is a lot. I'm doing a bunch of small things here. istype in init -> typecache, removing procs that are called once and loop over a list we JUST looped over (ph and the caching for reactions in particular) I am mainly trying to optimize copy_to here, since that's what foam spams As a part of this, I removed a pair of update_total and handle_reactions calls that were done on the reagents we are copying FROM I have no god damn idea why you would want to do that, but if anything is relying on the copy proc modifying the source, then that code deserves to break Speaking of, I cleaned up handle_reaction's main filter loop a lot, removed a lot of redundant vars and changed it from a full loop w tracker vars to an early exit pattern This meant using a loop label, which is unfortunate, but this is the fastest method, and it does end up cleaning up the code significantly, Which is nice Oh also I made the required_other var function even if there is no atom attached to the reaction, since I don't see why it wouldn't This last bit is gonna get a bit esoteric so bear with me Failing calls (which are most of them) to handle_reactions are going to be fastest if they need to check as few reactions as possible One reagent in a reaction's required list is marked as the "primary", and thus gets to trigger checking it. We need all the reagents to react anyhow, so we might as well only check if we have one particular one to avoid double checking Anyhow, in order to make most calls the fastest, we want these reactions distributed as evenly as possible across all our reagents. The current way of doing this is just taking the first reagent in the requirements list and using it, which is not ideal Instead of that, lets figure out how many reactions each reagent is in, then divy reactions up based off that and the currently divvied reactions This doubles the reagent index count, and takes the most common reagent, water, from 67 reactions to I think like 22 Does some other general cleaning in reagent code too, etc etc etc [Fixes runtimes from the forced gravity element being applied more then once](941d067611) I feel like this element should take a trait source or something to make them potentially unique, it's too easy to accidentally override one with another [Removes connect_loc usage in atmos_sensitive, replaces it with direct reg/unreg](de1c76029d) I only really used it because I liked the componentization, but it costs like 0.2 seconds off init alone which is really stupid, so let's just do this the very slightly harder way [Micros foam code slightly by inlining a LinkBlockedWithAccess call](744da3694c) This is in the space of like 0.05 seconds kinda save so I can put it back if you'd like, the double loop just felt silly [Changes how foam processes slightly](ee5e633e32) Rather then treating spreading and processing as separate actions, we do both in sync. This makes foam fade faster when spreading, which is good cause the whole spread but unclearing foam thing looks silly. It also avoids the potential bad ending of foam spreading into itself, backwards and forwards. This is better I promise. [Bumps fluid priority closer to heavy eaters, moves it off background](811797f09d) Also fixes a bug where foam would travel under public access airlocks. ## Why It's Good For The Game Saves a lot of cpu just in general, from both init and live. In theory makes foam faster, tho I'd have to test that on live at highpop to see if I've actually succeeded or not. Guess we'll see.	2023-07-17 08:56:24 -07:00
SyncIt21	fe9012d935	Adds general helper proc for processing atmos based on it's turf air contents (#75144) ... ## About The Pull Request Fixes this  Caused by this c8982bfb1c/code/modules/atmospherics/machinery/air_alarm/_air_alarm.dm (L305) Scrubbers will now call ` atmos_conditions_changed()` which starts processing based on the turf air contents which indirectly calls `should_atmos_process()` with the correct values. The same helper has been applied to the atmos sensitive component as well and other places ## Changelog 🆑 fix: runtime when turning scrubber's on via the air alarm UI refactor: `atmos_conditions_changed()` now starts atmos processing based on it's turf air contents /🆑	2023-05-16 05:03:09 -07:00
AnturK	4d6a8bc537	515 Compatibility (#71161) ... Makes the code compatible with 515.1594+ Few simple changes and one very painful one. Let's start with the easy: * puts call behind `LIBCALL` define, so call_ext is properly used in 515 * Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since src is now invalid there. * Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache directory is not appened to base path in browser controls so we don't check for it in base js and put the dev server dummy window file in actual directory not the byond root. * Renames the few things that had /final/ in typepath to ultimate since final is a new keyword And the very painful change: `.proc/whatever` format is no longer valid, so we're replacing it with new nameof() function. All this wrapped in three new macros. `PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is not actually necessary but if we get nameof that does not allow globals it would be nice validation. This is pretty unwieldy but there's no real alternative. If you notice anything weird in the commits let me know because majority was done with regex replace. @tgstation/commit-access Since the .proc/stuff is pretty big change. Co-authored-by: san7890 <the@san7890.com> Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>	2022-11-15 03:50:11 +00:00
Mothblocks	60ee087b16	Remove ELEMENT_DETACH on everything that doesn't need it, rename to ELEMENT_DETACH_ON_HOST_DESTROY + a PSA (about 0.2s init time savings) (#70972) ... ELEMENT_DETACH is **not** a requirement to having `Detach` called. Detach is always called when the element itself is destroyed. ELEMENT_DETACH is a flag that when set, makes sure Detach is called when the atom destroys. Sometimes you want this, for instance: ```dm /datum/element/point_of_interest/Detach(datum/target) SSpoints_of_interest.on_poi_element_removed(target) return ..() ``` This Detach cleans up a reference that would have hung if target was destroyed without this being called. However, most uses of Detach are cleaning up signals. Signals are automatically cleaned up when something is destroyed. You do not need ELEMENT_DETACH in this case, and it slows down init. This also includes somewhat more complex stuff, like removing overlays on the source object. It's getting deleted anyway, you don't care! I have removed all uses of ELEMENT_DETACH that seemed superfluous. I have also renamed it to `ELEMENT_DETACH_ON_HOST_DESTROY` to make its purpose more clear, as me and a lot of other maintainers misunderstood what it did, --- An update to this, ELEMENT_DETACH *is* needed for anything that can register to a turf, as turfs do not clear their signals on destroy.	2022-11-05 15:00:59 +01:00
Seth Scherer	f1a363c825	Converts a shitload of istypes to their more concise macros (#69260) ... * Converts a lot of istypes() to use their istype macro helpers.	2022-08-18 22:08:44 -04:00
Kylerace	8f0df7816b	(code bounty) The tram is now unstoppably powerful. it cannot be stopped, it cannot be slowed, it cannot be reasoned with. YOU HAVE NO IDEA HOW READY YOU ARE (#66657) ... ever see the tram take 10 milliseconds per movement to move 2100 objects? now you have https://user-images.githubusercontent.com/15794172/166198184-8bab93bd-f584-4269-9ed1-6aee746f8f3c.mp4 About The Pull Request fixes #66887 done for the code bounty posted by @MMMiracles to optimize the tram so that it can be sped up. the tram is now twice as fast, firing every tick instead of every 2 ticks. and is now around 10x cheaper to move. also adds support for multiz trams, as in trams that span multiple z levels. the tram on master takes around 10-15 milliseconds per movement with nothing on it other than its starting contents. why is this? because the tram is the canary in the coal mines when it comes to movement code, which is normally expensive as fuck. the tram does way more work than it needs to, and even finds new ways to slow the game down. I'll walk you through a few of the dumber things the tram currently does and how i fixed them. the tram, at absolute minimum, has to move 55 separate industrial_lift platforms once per movement. this means that the tram has to unregister its entered/exited signals 55 times when "the tram" as a singular object is only entering 5 new turfs and exiting 5 old turfs every movement, this means that each of the 55 platforms calculates their own destination turfs and checks their contents every movement. The biggest single optimization in this pr was that I made the tram into a single 5x11 multitile object and made it only do entering/exiting checks on the 5 new and 5 old turfs in each movement. way too many of the default tram contents are expensive to move for something that has to move a lot. fun fact, did you know that the walls on the tram have opacity? do you know what opacity does for movables? it makes them recalculate static lighting every time they move. did you know that the tram, this entire time, was taking JUST as much time spamming SSlighting updates as it was spending time in SStramprocess? well it is! now it doesnt do that, the walls are transparent. also, every window and every grille on the tram had the atmos_sensitive element applied to them which then added connect_loc to them, causing them to update signals every movement. that is also dumb and i got rid of that with snowflake overrides. Now we must take care to not add things that sneakily register to Moved() or the moved signal to the roundstart tram, because that is dumb, and the relative utility of simulating objects that should normally shatter due to heat and conduct heat from the atmosphere is far less than the cost of moving them, for this one object. all tram contents physically Entered() and Exited() their destination and old turfs every movement, even though because they are on a tram they literally do not interact with the turf, the tram does. also, any objects that use connect_loc or connect_loc behalf that are on the same point on the tram also interact with each other because of this. now all contents of the tram act as if theyre being abstract_move()'d to their destination so that (almost) nothing thats in the destination turf or the exit turf can react to the event of "something laying on the tram is moving over you". the rare things that DO need to know what is physically entering or exiting their turf regardless of whether theyre interacting with the ground can register to the abstract entered and exited signals which are now always sent. many of the things hooked into Moved(), whether it be overrides of Moved() itself, or handlers for the moved signal, add up to a LOT of processing time. especially for humans. now ive gotten rid of a lot of it, mostly for the tram but also for normal movement. i made footsteps (a significant portion of human movement cost) not do any work if the human themselves didnt do the movement. i optimized has_gravity() a fair amount, and then realized that since everything on the tram isnt changing momentum, i didnt actually need to check gravity for the purposes of drifting (newtonian_move() was taking a significant portion of the cost of movement at some points along the development process). so now it simply doesnt call newtonian_move() for movements that dont represent a change in momentum (by default all movements do). also i put effort into 1. better organizing tram/lift code so that most of it is inside of a dedicated modules folder instead of scattered around 5 generic folders and 2. moved a lot of behavior from lift platforms themselves into their lift_master_datum since ideally the platforms would just handle moving themselves, while any behavior involving the entire lift such as "move to destination" and "blow up" would be handled by the lift_master_datum. also https://user-images.githubusercontent.com/15794172/166220129-ff2ea344-442f-4e3e-94f0-ec58ab438563.mp4 multiz tram (this just adds the capability to map it like this, no tram does this) Actual Performance Differences to benchmark this, i added a world.Profile(PROFILER_START) and world.Profile(PROFILER_START) to the tram moving, so that it generates a profiler output of all tram movement without any unrelated procs being recorded (except for world.Profile() overhead). this made it a lot easier to quantify what was slowing down both the tram and movement in general. and i did 3 types of tests on both master and my branch. also i should note that i sped up the "master" tram test to move once per tick as well, simply because the normal movement speed seems unbearably slow now. so all recorded videos are done at twice the speed of the real tram on master. this doesnt affect the main thing i was trying to measure: cost for each movement. the first test was the base tram, containing only my player mob and the movables starting on the tram roundstart. on master, this takes around 13 milliseconds or so on my computer (which is pretty close to what it takes on the servers), on this branch, it takes between 0.9-1.3 milliseconds. ALSO in these benchmarks youll see that tram/proc/travel() will vary significantly between the master and optimized branches. this is 100% because there are 55 times more platforms moving on master compared to the master branch, and thus 55x more calls to this proc. every test was recorded with the exact same amount of distance moved here are the master and optimized benchmark text files: master master base tram.txt https://user-images.githubusercontent.com/15794172/166210149-f118683d-6f6d-4dfb-b9e4-14f17b26aad8.mp4 also this shows the increased SSlighting usage resulting from the tram on master spamming updates, which doesnt happen on the optimized branch optimized optimization base tram.txt https://user-images.githubusercontent.com/15794172/166206280-cd849aaa-ed3b-4e2f-b741-b8a5726091a9.mp4 the second test is meant to benchmark the best case scaling cost of moving objects, where nothing extra is registered to movement besides the bare minimum stuff on the /atom/movable level. Each of the open tiles of the tram had 1 bluespace rped filled with parts dumped onto it, to the point that the tram in total was moving 2100 objects. the vast majority of these objects did nothing special in movement so they serve as a good base case. only slightly off due to the rped's registering to movement. on master, this test takes over 100 milliseconds per movement master 2000 obj's.txt https://user-images.githubusercontent.com/15794172/166210560-f4de620d-7dc6-4dbd-8b61-4a48149af707.mp4 when optimized, about 10 milliseconds per movement https://user-images.githubusercontent.com/15794172/166208654-bc10086b-bbfc-49fa-9987-d7558109cc1d.mp4 optimization 2000 obj's.txt the third test is 300 humans spawned onto the tram, meant to test all the shit added on to movement cost for humans/carbons. in retrospect this test is actually way too biased in favor of my optimizations since the humans are all in only 3 tiles, so all 100 humans on a tile are reacting to the other 99 humans movements, which wouldnt be as bad if they were distributed across 20 tiles like in the second test. so dont read into this one too hard. on master, this test takes 200 milliseconds master 300 catgirls.txt when optimized, this takes about 13-14 milliseconds. optimization 300 catgirls on ram ranch.txt Why It's Good For The Game the tram is literally 10x cheaper to move. and the code is better organized. currently on master the tram is as fast as running speed, meaning it has no real relative utility compared to just running the tracks (except for the added safety of not having to risk being ran over by the tram). now the tram of which we have an entire map based around can be used to its full potential. also, has some fixes to things on the tram reacting to movement. for example on master if you are standing on a tram tile that contains a banana and the TRAM moves, you will slip if the banana was in that spot before you (not if you were there first however). this is because the banana has no concept of relative movement, you and it are in the same reference frame but the banana, which failed highschool physics, believes you to have moved onto it and thus subjected you to the humiliation of an unjust slipping. now since tram contents that dont register to abstract entered/exited cannot know about other tram contents on the same tile during a movement, this cannot happen. also, you no longer make footstep sounds when the tram moves you over a floor TODO mainly opened it now so i can create a stopping point and attend to my other now staling prs, we're at a state of functionality far enough to start testmerging it anyways. add a better way for admins to be notified of the tram overloading the server if someone purposefully stuffs it with as much shit as they can, and for admins to clear said shit. automatically slow down the tram if SStramprocess takes over like, 10 milliseconds complete. the tram still cant really check tick and yield without introducing logic holes, so making sure it doesnt take half of the tick every tick is important go over my code to catch dumb shit i forgot about, there always is for these kinds of refactors because im very messy remove the area based forced_gravity optimization its not worth figuring out why it doesnt work fix the inevitable merge conflict with master lol create an icon for the tram_tunnel area type i made so that objects on the tram dont have to enter and exit areas twice in a cross-station traversal add an easy way to vv tram lethality for mobs/things being hit by it. its an easy target in another thing i already wanted to do: a reinforced concept of shared variables from any particular tram platform and the entire tram itself. admins should be able to slow down the tram by vv'ing one platform and have it apply to the entire tram for example. Changelog cl balance: the tram is now twice as fast, pray it doesnt get any faster (it cant without raising world fps) performance: the tram is now about 10 times cheaper to move for the server add: mappers can now create trams with multiple z levels code: industrial_lift's now have more of their behavior pertaining to "the entire lift" being handled by their lift_master_datum as opposed to belonging to a random platform on the lift. /cl	2022-06-24 13:42:09 +12:00
LemonInTheDark	6fcbce39cd	Makes turfs persist their signals, uses this to optimize connect_loc (#59608) ... * Makes turfs persist signals * Splits connect_loc up into two elements, one for stuff that wishes to connect on behalf of something, and one for stuff that just wants to connect normally. Connecting on behalf of someone has a significant amount of overhead, so let's do this to keep things clear * Converts all uses of connect_loc over to the new patterns * Adds some comments, actually makes turfs persist signals * There's no need to detach connect loc anymore, since all it does is unregister signals. Unregisters a signal from formorly decal'd turfs, and makes the changeturf signal persistance stuff actually work * bro fuck documentation * Changes from a var to a proc, prevents admemems and idiots * Extra detail on why we do the copy post qdel	2021-06-22 23:12:34 -04:00
LemonInTheDark	27385e9d70	Converts the atmos senstive component over to connect_loc (#58266) ... * Makes all uses of atmos_senstive pass in mapload as context * Converts atmos senstive to connect_loc, does some general cleanup to the element, and makes it check the state of the tile the thing is on assuming creation didn't happen as a part of map loading * Updates connect loc to match the new arg list	2021-04-30 18:35:47 -07:00
Emmett Gaines	1c81adac8d	Allows the connect_loc element to have a listener different from the tracked object (#58276)	2021-04-10 18:19:57 -07:00
LemonInTheDark	8823354ac1	Increases the clarity of firealarms (#56188) ... ## About The Pull Request Makes firelocks closed by atmos issues open when those issues are resolved Adds a finished proc to atmos_sensitive Adds a new overlay for fire alarms that are currently triggered due to atmos issues Makes the detecting var work properly instead of shutting off behavior until the next activity (This avenue needs more work put into it, but that's out of scope for this pr) ## Why It's Good For The Game I've been getting "complaints" from players about firelocks and cold, and while I think part of it is stuff that will smooth out over time, they do have a point. So let's make fixing firelocks less of a shot in the dark, and more of a minigame.	2021-01-16 13:52:30 -05:00
LemonInTheDark	6d1cb94ffb	LINDA Reforged (#55604) ... Speeds up gas movement significantly Documents the intent and finer details of the atmos system (Thanks dunc) Fixes excited groups constantly rebuilding, this broke 4 years ago Fixes superconductors just straight up not working Allows turfs to sleep while inside an excited group Adds a new subprocess to SSAir to support rebuilding in this state Most heat based behavior no longer relies on being inside a fire Adds a new element to support doing this cleanly Adds a new subprocess to SSAir to support doing this while a turf is asleep Refactors air_update_turf to allow for finer control Makes apcs take damage in heat to prevent infinite plasma fire diffs Cleans up immutable gas mixtures to make them work properly when the mix has gas in it Planetary turfs no longer create a new copy of themselves each time they process. We instead use a global immutable mix Cleans up a typed for loop in reactions Canisters will take damage from outside heat now Speeds up excited group dismantle Increases the superconductor threshold by 200k Cleans up some roundstart ATs on some ruins Uses /turf/open/var/excited to track if a turf is actively processing, preventing a |= Prevents openspace from trying to melt Tweaks a canister examine line Makes planetary turfs reset to base when broken down as part of an excited group Makes it impossible for planetary turfs to rebuild, just like space tiles Fixes closed turfs not activating their replacement when destroyed by moving closed -> open turf activation to the adjacent air subsystem. They were activating and then going back to sleep before adjacent air got a chance to tick. Fire alarms will trigger when the area gets too cold for humans	2021-01-08 08:14:08 +01:00