ID:151408
 
So currently in my project I'm trying to make everything run as efficiently and smooth as possible, weeding out unused or redundant checks/loops/variables/whatnot.

However, waaay in the beginning when I started I didn't much bother assigning classes like I should (like mob/Player, mob/Monster, etc)

Now, for instance, Monsters have access to variables/procs which will only ever occur to players. Let's roughly say about 30 procs, 25 variables (including about 10 lists) which are attached to the NPC Mobs, but only ever used by PCs.

Would it be worth making the /Player subclass and editting a lot of the code to typecast stuff to mob/Player, or will leaving it this way not really affect the game's efficiency?
It doesn't affect efficiency beyond the fact all monsters sit in memory with player variables currently. What is really lets you do is remove redundant and potentially buggy code that checks what you're dealing with (is it a monster, or a player?).

If you want, you could actually post some profiling output of your game under a heavy load, and show us relevant code related tot he time-consuming functions.
In response to Stephen001
I might do that, because sometimes the profiler goes mental. Real-Time CPU getting to numbers above trillions is a bit.. odd. And heck, I wouldn't even understand what all of the columns mean.
In response to Emasym
I've noticed that realtime issue with other games, typically big Anime games. Having looked at their code, they could use clean-up too. XD
In response to Stephen001
Bit of a generalisation there. Any (wanna-be) action-packed game will have a lot of checks running, which may or not may be handled efficiently. It's a pain, truly.

I've shortened the profile down to where some problems may be, you can view it here/

Most of them involve movement, which is no surprise as turf/Entered() loops, Move() has its limitations and delay, and bumping triggers a number of things.
In response to Emasym
No, I was saying that's where I've personally seen it crop up a lot.

What is the performance issue you are seeing from a user's point of view?
In response to Stephen001
On a good host, really not that many, even though some of the numbers may appear high. Some lock-ups on the user's end when someone chooses new hair or gets another colour aura (RGB proc). Though random small freezes do occur at times, and pin-pointing the correct cause is quite a pain.

A big problem is finding a way to make s_damage or F_damage suitable for a LOT of numbers at the same time. I tried F_damage, then was forced to switch back to s_damage (which isn't all that performant either) because F was creating MAJOR lockups.
In response to Emasym
As I updated F_Damage for caching a little while ago, maybe we should work on that first. Can you provide some examples of how you're calling F_Damage (or s_damage now)?
In response to Stephen001
Pretty much default. Even disabled the checks to see if it's a colour code (#000000)

s_damage(src, amount, "[attacker.client ? "#0000ff" : "#ff0000"]")


The caching thing made it go mental. People saw 1s when logging in.
In response to Emasym
Just for final reference, what order of magnitude of numbers are we talking here? F_Damage should pop big ones into exponent form.
In response to Stephen001
Anything from 8 to about 20.000.
In response to Emasym
I'm guessing the size isn't the issue there, then. I've found some issues for performance when called a lot, one set that's F_Damage specific and one that's general to these types of libraries.

Firstly a note on F_Damage itself. F_Damage doesn't actually give time for BYOND to flick() the icon as it assumes you will do that by some other means (say exiting the function quickly after). If it's a long process, sleep(1) will let flick() progress, but ideally your procs that use F_damage wouldn't be long running. If they are, then you won't see the flick() until all is done. I'm tempted to add an option for this sleep in F_Damage.

Secondly, F_Damage is meant to scale to atoms of any size, even if they aren't world.icon_size. This however carries a small overhead, I've added an option to assume world.icon_size, so it doesn't hit the RscFile to grab the size of the thing you want to flick on.

Thirdly, we were excessively spawning and hard-deleting elements. I've changed this now.

Finally, is an issue that relates to both F_Damage and s_damage. Both libraries operate by adjusting Pixel offsets on a base icon to place digits. Unfortunately, BYOND caches every new icon we "create" by this in the RscFile, which incurs a penalty regardless of how you cut it. As the digit positions vary a lot, I'm not sure this could easily be improved upon.

I'm now down to this:



However it can't really be squeezed much more. You are liable to see different performance, due to what else is going on. I could probably make an event scheduler version of F_Damage that would help the situation further.

At a guess, players will sometime hammer a lot of calls to F_Damage / s_damage in close succession? The real-time seen is because flick() just happens to take time to render.
In response to Stephen001
An update with all that would be amazing. I had already disabled F_damage grabbing all the info about the icon on which it should appear, as it just seemed like nitpicking for something that short a duration.
In response to Emasym
Yeah, it was essentially to make things like huge bosses work properly. I'll have to push an update via the hub tomorrow for this, and you can try it.
In response to Stephen001
I might be wrong but if a proc doesn't return but keeps running, does that not make it feasible for it to have a big realtime? doesn't the cpu affect the decision more? personally i only use realtime to check for what procs should be made in to background processes; if i haven't done so already.
In response to Rapmaster
That is the case, however the real-time can be for related functions (like file I/O) that are completing off the back of that function. In that case, it's usually useful to note it.
In response to Stephen001
Huge improvement over the old one. HUGE. Getting 0.000 CPU on average. Offline, though, can't properly test online yet.

Grabbing the icon width seems to be quite an ordeal for BYOND.