Looking at the most recent code I have from you, I'm seeing some things worthy of your attention.

1) Statbar_Refresh() is an ongoing loop instead of only updating on demand, which you have a todo note for. Ideally, what you want is something you can call on demand that also has a bit of "debounce" in it so multiple calls on the same tick won't have it update multiple times.

2) You also have a very, very weird piece of code in Statbar_Refresh() that ensures even logging-out clients won't stop this proc from running:


That seems like really bad juju to me. While I don't think this is contributing anything to your woes, because it should never have an impact unless a player is logged in only a very short time, and even then it would only result in a useless proc called every 5 seconds to do nothing, it has no business being there.

3) Speaking of debounce, checkwinset() would benefit from that.

4) Also not a real factor, but in regeneration.dm you have a couple spawn() statements right next to each other with the exact same timing. The statements really should be part of the same block, so you're only resuming a spawned proc once instead of twice.

5) Quite a few routines do a sleep(N) before an empty spawn(). Effect on performance is minimal, but don't do that; do spawn(N) instead. You're just adding to proc call overhead for no reason.

6) DoCooldown() in Skill.dm looks like it's being done for all skills, and you have a todo note about improving performance by switching to another system. Seems like a good idea to do so.

7) WorldLoop_Status() is calling itself, without using spawn(). The set waitfor=0 line probably removes the possibility of infinite recursion, but for sanity's sake you should always, always use a spawn in a case like this.

8) You have like a million world/New() overrides defined, and it looks like Login() has something similar. This is not a good idea. Put these procs together under a single proc instead of relying on ..() to chain everything.

Now most of this is nitpicky stuff and I basically gave up after a while because I was getting into the weeds; there might be a nasty loop in here somewhere that isn't showing itself, or at least isn't showing up within my attention span. A lot of the above is just issues of form, although a couple of those things--debouncing some procs and replacing the skill cooldown system--will probably have a bigger impact overall.

However I think it would be a really good idea for you to get detailed profiling results for the cases when you have 60 players, 90, etc., and especially when the CPU starts to run away on you. You said the profiler didn't show anything suspect, but I don't know if you've done that kind of comparison yet--and even if you have, extra eyes on the problem would not hurt. If nothing else it would be good to have a handle on which procs are using up those CPU cycles and see if those particular procs can be improved upon.

What I'm saying is, a single profile isn't enough to help. You need multiple profiles, and to keep track of roughly how many players are on when each one is made. Get maybe a minute worth of sample time to see what's running, and that should make for good comparisons.

Armed with that data, it should be possible not only to identify problem areas in your own code, but also perhaps to see if maybe anything in BYOND could be exacerbating matters on the backend. The latter is tricky because not everything that might happen on the backend would show up in the profile, but it's possible there could be an echo of something useful.

Overall though, I really don't see how it's possible that server performance would have downgraded at all in 512. If anything you should be seeing an improvement. The only things that changed appreciably under the hood would result in slight speedups, but nothing should be slowing down.

Here are profiles over the span of about a minute of activity:
50 players: https://pastebin.com/MEj2yngs
68 players: https://pastebin.com/KAJnGQ4g
72 players: https://pastebin.com/N2gYDpsB
75 players: https://pastebin.com/bKSe6cAJ

The last two profiles had a turf war going on where it's at least 10 vs. 10 battling on a map. The code for that is in war.dm.

I have not downgraded yet. I figured before I try that, I'll try changing the map_format back to tiled. One of the conversations I had indicated that the problem was associated with map rendering. I'm already seeing improvements on a local server; CPU no longer jumps around between 0-2 with just me and AI active, it sits at a firm 0). We'll see tomorrow though.

If you use a lot of big icons, it's conceivable that was having some impact with the visual bounds code. However that really shouldn't come up a lot unless those big icons are getting updated a lot, which for turfs at least shouldn't be the case. Also I don't think that would be likely to get appreciably worse with more players, unless most of the big objects are created through their activity.

Here's something I noticed: If you're not using tiled mode, then it looks like all of the code having to do with the Grabbed var is useless. If you were to get rid of that, or wrap it up in an #ifdef or #ifndef block, you could get rid of atom/movable/Del() with it and save a crapload of time.

And in fact, your code isn't calling Expand() anywhere. The only place it could get called is commented out.

Right now your code is overriding atom/movable/Del() for literally no reason, and that's the biggest regular CPU user in all of your profiles.

So I found something that could be the cause thanks to that tip from MrStonedOne. *crosses fingers*

Also I'll remove that extra Del() override.

likely something sleeping in a endless loop using cpu. profiles don't show procs until they finish (unless the profile was started before the proc), so a proc that sleeps in a endless loop would never finish and would never show up on a profile.