I remember someone saying that this sometimes tends to happen even if it's only a few movables moving for a long time. More importantly it seems that the client performance decrease gets worse without new objects appearing which is counter-intuitive.

Kumorii wrote:

I don't believe this is a bug. You're just hitting the ceiling of the renderer. Having hundreds of movables on the screen at once; each moving around has always taken a toll on DS' renderer. I agree it would be awesome to see some improvements to this limitation, though.

Even a surplus of stationary objects can cause the renderer to chug a little bit. This is something I've struggled with for FEED a fair bit, but ultimately it's manageable ime. I can't think of a case where 100s of movable entities should be all drawn in view of a client at once.

Thanks for making me take another look back at this; it's clearly not a perf issue from simply having "too many moving objects", because you can easily trigger it with even just 20 (and probably even less).

I was making the mistake of lowering the conveyor belt speed to the minimum 0.025, under the impression that more movement = more lag. But it looks like 0.075 or 0.1 are the prime spots; with even just 20 objs the client is now getting extremely chunky performance.

If your theory was correct, the same number of moving objects would cause this issue if they did not overlap into the same tiles at any point during their movement cycle, yes?

You should test it that way.

The issue is not a BYOND bug. This particular false positive is caused by a very understandable, but incorrect reckoning of the workload this particular situation puts on the server.

The real problem is that since all of these objects are overlapping, and moving one after the other, you wind up with an insane number of Cross()/Uncross() calls under the hood that wind up being a major performance issue.

In reality, the engine can handle tens of thousands of moving objects. The problem is when they start to get stacked up on top of one another. The more clustered movable activity is in the engine, the worse it handles it.

On the other hand, you may have found a new wrinkle to the problem if what you say is true, and this can be triggered by just 20 objects with minimal overlap.

Ter13 wrote:

The issue is not a BYOND bug. This particular false positive is caused by a very understandable, but incorrect reckoning of the workload this particular situation puts on the server.

The real problem is that since all of these objects are overlapping, and moving one after the other, you wind up with an insane number of Cross()/Uncross() calls under the hood that wind up being a major performance issue.

In reality, the engine can handle tens of thousands of moving objects. The problem is when they start to get stacked up on top of one another. The more clustered movable activity is in the engine, the worse it handles it.

On the other hand, you may have found a new wrinkle to the problem if what you say is true, and this can be triggered by just 20 objects with minimal overlap.

Are you always this condescending or did I just catch you at a bad time? The amount of arrogance here is incredible. "If what you say is true" -- did you even bother looking at the video, or running the test case, or indeed investigating anything before you ran in here deciding that this was clearly not a bug at all, but a limitation of the engine because poor little BYOND can't handle 200 circles with no code moving around?

It's incredibly frustrating to narrow down a reproducable test case, provide some information on what's going on, and even demonstrate various different ways that this issue plays out, only for you to come in here and decide that it's not actually a bug but a completely unrelated non-issue, without even (apparently) looking at anything I posted.

Like, seriously. "If what you say is true" -- I posted a god damn test case. You can download it. You can run it. You can see the exact same problems that I'm reporting. It takes maybe three minutes at most because all you have to do is extract it, click the DME, and then hit "Compile + Run". The least you could do is fucking try it before you treat me like I'm clueless.

---

Anyway, I recorded a new video showing that this occurs with even five objects, it just takes a decent while longer for it to manifest. This is also running as a local instance and not a server, but you can see that the CPU % barely flickers to even 1% during this even though the game is visibly slowing down.



And here is the updated test case (6 KB). It is configured exactly as I have it in the video and you can reproduce the results by turning on the spawner and waiting.

The video includes another demonstration of 200+ objects and shows the CPU% meter functioning and the slowdown becoming far more severe. Also demonstrates that making the movement faster seems to paradoxically cause less slowdown!


E: Music not included, of course :)


E2:

i just tested 30 objects with no overlap at all and it still has the problem. profiling the client shows that GetMapIcons usage continues to grow over time as if there were some sort of "leak"

I've gotten it to run really poorly before 'snapping' back to full speed for a bit before it slows down again. It sounds like a leak is plausible, with the GC running causing it to speed up again until the leak starts to manifest. Nice catch!

E: I'm not sure why this first part is showing up in bold. BYOND.


Kumorii wrote:

I think you took a lot of offense from something that didn't have any hostility behind it. I digress though.

It might not have been hostile, but it was arrogant to the point of farce. I outlined exactly why I was unhappy with that reply, and pretty much everyone that I've shown this who develops BYOND things agrees that reply was remarkably shitty and dismissive. But I digress, because it happened again:

but a limitation of the engine because poor little BYOND can't handle 200 circles with no code moving around?

BYOND does not handle hundreds of entities moving around on a single screen at once very well at all. It never has and controlling the amount of objects and mobs you have in view of a client is one of the headaches with developing games on the engine. Not that I think this is explicitly the issue you're encountering.

I'm not sure why you are all so quick to say that BYOND's engine is garbage. This is really confusing to me, because while BYOND definitely has its share of performance woes, "moving around 5 objects" is not something I would consider to be difficult (again: see the above video.) Even at 300 objects spinning around, BYOND is barely reporting 15% cpu usage. This is a client perf issue, not a BYOND game engine issue.

---

Here. I have attached yet another video because two wasn't enough.

This video has two clients with the code running in dreamdaemon. You can VERY CLEARLY!!!!! see that the engine itself is fine. The game is running normally. The client is choking to death on this. The client (renderer) is incapable of handling it.



You can see that one client that keeps only a small part of the conveyor belt runs fine (mostly), while the one with the full thing in view starts to die and in fact actually became completey unresponsive during recording (it got better). If this doesn't prove that it's a client side renderer then I'm not sure I could convince you the sky is blue either.

I have gotten the test case to produce the described performance issues at ~150 spawned entities. However, I'd be willing to argue that it could be to do with your code.

(sigh)

This test case is littered with pretty poor practices.

Yes, it's a test case, developed to do as little as possible beyond causing the bug.

You're abusing New() with loops a ton, not using any ..() calls,

If you can demonstrate that any of this matters I will eat a corn dog.

---

and I can't help but get the feeling that using walk() for your conveyors is a big part of the performance tanking. The walk() procs are pretty terrible

well boy howdy is it a good thing we have a bug report here about how bad they are so they can be fixed, huh!!!!!!!!!!!!!!!!

and I often avoid them at every possible turn because just a few simultaneous walk() calls absolutely tanks performance. Also, walk() doesn't stop until told to stop. I don't see where you're telling your things to stop walking unless the conveyors get disabled. I think step() would be much better in this case.

After some fiddling around, i'm tempted to say the issue is with using walk() and calling it every single tick; often leading to multiple walk() calls being called on a thing before it moves out of the conveyor space.

Instead of peanut posting, I actually changed the walk() calls to use step() instead.



walk() says "just keep moving in this direction until you're told to do otherwise, at a set speed". That's exactly what I want a conveyor belt to do. To use step(), I now need to consider when something entered the space, how fast it was moving (because as you can see, the change is instant -- things are moved multiple times in one tick because they hit the conveyors as they're processed) and when something exits it. It involves a lot more overhead that is immensely simplified by using walk().

Note: this issue only occurs when `world.movement_mode` is set to `LEGACY_MOVEMENT_MODE`

the path "noodling" is a glide_size issue, if you set the glide_size to 32/(move_lag/world.tick_lag) it'll stop cutting corners. it's running smooth for me with 700+ objects when in TILE_MOVEMENT_MODE



while not seen in the gif i am seeing some objects fly off the belt, but that's definitely unrelated to the bug report
(edit: i changed to step() from walk() and the objects no longer fly away)

this bug report is something wrong with LEGACY_MOVEMENT_MODE

RootAbyss wrote:

the path "noodling" is a glide_size issue, if you set the glide_size to 32/(move_lag/world.tick_lag) it'll stop cutting corners. it's running smooth for me with 700+ objects when in TILE_MOVEMENT_MODE

while not seen in the gif i am seeing some objects fly off the belt, but that's definitely unrelated to the bug report
(edit: i changed to step() from walk() and the objects no longer fly away)

this bug report is something wrong LEGACY_MOVEMENT_MODE

sweet catch! i think the things flying off might be related to multiple steps being taken before a loop procs, so it 'steps over' the conveyor that would redirect it. step would fix this since it'd only ever move once.

using step() this way, do you get the same jumping behavior where things will visually skip over segments like in the GIF i posted earlier? i'm not sure how to solve that one without additional tracking to make an object not get moved multiple times in a single tick.

E: This GIF in specific. I changed walk() to step() with no other changes.

No offense was intended, but it was taken, and ultimately I have a part in that. I'll bow out, because there are new changes to the implementation that I haven't been able to fully test that could be impacting this report, and you are ultimately correct that my approach was lacking grace or tact.

In my defense, this is a situation that was extensively tested back before the 500 series, and the engine never performed well, and at the end of it all, it was determined that the impact, given the choices of the implementation was reasonable.

The "if what you say is true bit" wasn't meant to be a sleight, but a self-aware bit of conversational charity that was meant to try to undercut the tone of dismissal the above could have been read as if read without charity.

But ultimately, you are right. I had very little research in the topic or hard metrics, given my current time constraints and never should have butted in without taking that time to gather metrics. Apologies for the offense.