Unusual Performance Issue due to SM Update

[FerenGraves]

Issue Description:
I've noticed a critical decline in performance when running a local test server.

These were obtained during my attempts to pinpoint the issue and were performed on a fresh Paradise Master Branch download with no modifications:

Post-round start:
Profile Log ~25m.txt

This is the timer prior to round start but post initialization (the B value climbs roughly at 4-6k per tick):

The only other value within the MC tab that was abnormal was the CPU, with spikes of 600-700.

Due to the fact that this issue does not appear on the live server, nor popped up during testing, nor was it reproducible by another party lead us to believe it is in some regard hardware-related.

What did you expect to happen:

My potato to have same level of performance as prior to the SM Update.

What happened instead:

My potato is on fire.

Why is this bad/What are the consequences:

Anyone facing similar issues will be unable to perform local testing for their projects.

Steps to reproduce the problem:

1. Download a fresh Paradise Master Branch
2. Compile it in your program of choice (Dream Maker was used in my instance)
3. Run it on a local server (Dream Daemon was used in my instance)
4. Either see everything go really badly or nothing out of the ordinary happens at all.

When did the problem start happening:

After merging a batch of commits into my outdated master that contained The Suppermatter Update (#15291) among them.

Extra information:

By reverting the commits one by one I was able to narrow down the culprit to the SM Update, as once it was reverted the performance of my test server went back to normal.

[hal9000PR]

RIP Feren's potato

[AffectedArc07]

Proc Name                     Self CPU    Total CPU    Real Time     Overtime        Calls
-------------------------    ---------    ---------    ---------    ---------    ---------
/proc/qdel                      39.475      629.852      630.905       39.280      3699816

Send your qdel.log

[farie82]

/proc/addtimer                                                                                   10.129      238.874      239.076        0.088       643401
/datum/timedevent/New                                                                           216.330      228.757      228.932      187.229       643401
/obj/machinery/door/proc/autoclose                                                                1.357      153.228      162.241        0.000       381925
/obj/machinery/door/airlock/close                                                                 1.532      151.875      160.871        0.003       382024
/obj/machinery/door/airlock/close                                                                 5.674      149.975      158.987        0.018       382024
/obj/machinery/door/proc/autoclose_in                                                             1.768      143.607      143.721        0.003       381927
/datum/looping_sound/proc/sound_loop                                                              2.213      113.858      113.924        0.001       259775
/proc/qdel                                                                                        6.305       90.626       90.793        6.162       627596
/datum/timedevent/Destroy                                                                        79.457       82.804       83.047       79.369       603765

is rather interesting. I've looked into it a bit and it looks like the timer system is ... somehow broken.
Autoclose calls close. Which can call autoclose_in again. but on a timer of 60 (6 seconds).
sound_loop is also timer based and should not be called this often

[FerenGraves]

Proc Name                     Self CPU    Total CPU    Real Time     Overtime        Calls
-------------------------    ---------    ---------    ---------    ---------    ---------
/proc/qdel                      39.475      629.852      630.905       39.280      3699816

Send your qdel.log

Not from the same session but should be the same cause:

qdel.log

[AffectedArc07]

Solved. User did not have config files loaded.