Later tonight I'm going to try a few variations of this test where I test the specific variations that appear.
Namely,
-regular procs
-datum procs
-client procs
I'll try isolating each type to see if removing any of them from the experiment changes my results.
I've tested various occurrences with this again lummox. And the information I've gained may be of use given some more information of the inner workings of right clicking.
What I tested: -Changing all client/procs to a datum/proc - caused no change in right click latency, measurement was still exactly the same -Logging in as an admin vs logging in without any admin powers - if no admins log in the speed of right click never changes/slows down leading to the idea that adding procs to client/verbs slows down right click for everyone -I also tested a basic byond case where 100 procs were added and remove from client/verbs - right click latency was nowhere near as intense as it was in ss13 but it was measurable when used on a very large stack of objects What I saw in testing: -Adding procs to any client's client/verbs variable slows the right clicking menu opening for all clients who lack those procs in client/verbs -Removing these procs from your own client/verbs makes your right click slower, even if all clients no longer have these procs in client/verbs -It isn't simply the number of procs involved, as I made a test case where 100 null procs were added/removed to client/verbs and the speed change wasn't nearly as much as it is in ss13 My questions: -Is there some kind of server-side master verbs list a client needs to check against before it can open a right click menu? -Why doesn't that master verbs list remove a proc if all clients no longer hold that proc? -Is it downloading the procs themselves (which would explain why ss13 has longer wait times than my test case)? Here is the test case where I tried it in an empty byond project http://puu.sh/jvPYO/e64b3f0f3c.dm I found that adding 100 empty procs to the client/verbs list and removing them caused about a 20% measurable increase in slowdown, ss13 experiences about a 100-150% slowdown from fewer client/verbs procs. And just as in ss13, if you have all the procs readded to your client/verbs again you have the optimal speed you did before any proc was added to client/verbs. | |
Clusterfack wrote:
-Logging in as an admin vs logging in without any admin powers - if no admins log in the speed of right click never changes/slows down leading to the idea that adding procs to client/verbs slows down right click for everyone Everyone? That's really odd. It should only impact the client itself. -Adding procs to any client's client/verbs variable slows the right clicking menu opening for all clients who lack those procs in client/verbs That's very, very strange. The right-click menu should be based on the available verbs, which include those in client.appearance. It definitely shouldn't be considering verbs that aren't available at all, and for this type of verb that's a process I would expect it can go through fairly quickly. I do know that DS will only look at the verbs it's been told about, and once you're given a verb it makes sense that your client would now have info about it. But it shouldn't impact other clients; the only way they'd ever hear about the proc then is if it got added to a mob instead of a client, and they saw that mob. -Removing these procs from your own client/verbs makes your right click slower, even if all clients no longer have these procs in client/verbs So to clarify, you're seeing a certain speed A before you add the verbs to your client, and it's about the same after adding them, but it's a slower speed B when you remove them again? My questions: No. When opening a right-click menu, AFAIK the only server lookups involved would be when otherwise available verbs (passing all other tests) need to check if an object is in its argument list. That is, verbs of the type MyVerb(obj/O as obj in world) would involve a server lookup. -Is it downloading the procs themselves (which would explain why ss13 has longer wait times than my test case)? No, but it does download info about the procs when it "sees" them. For instance, whenever an appearance is sent, it comes with a verbs list. DS will check the verbs against its known verbs and if it finds it isn't aware of one, it asks the server for info. In that way it can understand the arguments needed, the "set src" value, etc. for parsing purposes. Here is the test case where I tried it in an empty byond project Very interesting info. I'll have to run some tests on that soon and try that out. There may be something misbehaving in the parser (or the related routines that handle right clicks, anyway) that would account for this. | |
So to clarify, you're seeing a certain speed A before you add the verbs to your client, and it's about the same after adding them, but it's a slower speed B when you remove them again? Yes essentially what I have seen is that when you lack procs that were added to any connected client's client/verbs var at any time, right click speed slows down. The speed is approximately the same before/after adding more procs to client/verbs, but after you lack them there is a measureable slowdown. So this includes the case where procs are added to your client/verbs and removed. And even if no client/verbs has those procs at all the slowdown is still measurable (if only about 3 seconds extra out of 12 normal seconds, the timing is consistent and repeatable enough to not be an error) In my test case I spawn a very large number of simple objects onto the map, clicking them takes about 12 seconds before adding anything to client/verbs, after you add the 100 procs to client/verbs clicking still takes about 12 seconds, but once you remove them all it takes approximately 15. | |
When you find this, Please give us a detailed breakdown of how the code was causing this to happen.
Like, this is the kind of bug that belongs in a museum to remind new coders the dangers of coding recklessly. | |
So this bug wasn't quite fixed by ID:2084104
So i'm gonna bump it. There seems to be some improvement, but not enough. a tile with 10 items still takes about 1.8 seconds to open the right click menu. | |
Good to know, although it's a shame this wasn't fixed by that. I still think the only way I'll get to the bottom of it is with a test case. That's what finally cleared things up for the other bug.
| |
I have a sneaking suspicion that similar to the bug where you could right click over darkness with SEE_PIXELS, that this is also a matter of the scoping of verbs. Either "in world", or "in view()", etc.
| |
The more you can condense this down into a simple test, the quicker I can isolate the issue and fix it.