Doubtful, sybil was on 1332, and i disabled certain things like that to test, i even flat out disabled the entire master controller's ticking, to test. no improvement on shuttering.
It also happened at round start, before things that caused similar particle effects to trigger on our code.
Lets get a thread opened for this topic thou, to help organize info http://www.byond.com/forum/?post=2057211
the hope is to differential diagnos this.
Dunc wrote:
There's definitely a correlation between more connected clients and lag. No. The map chunk system works as follows: 1) Objects get marked as having "dirty" positions, as needed. - Turfs that were previously "out of bounds", have been given an out-of-bounds appearance, or have had an image/animation change are marked. - All movables are marked when they are placed on the map, and are also marked if they're known to be in a chunk and get removed from the map. 2) At the beginning of the map loop, dirty objects get updated and may be removed from or added to chunks. This typically is going to take longest right at the beginning of the world, and afterward shouldn't be a problem. 3) At the beginning of each client's map routine, objects in their personal chunk are all marked as "ready to delete" from the chunk. Then, the chunks in their view are iterated through. Any special turfs (out of bounds), all movables, and any turfs that out-of-bounds movables are on, are added to the player's personal chunk. 4) The turf routines look for changes in the personal chunk regarding special turfs, and the movable routines look at all objs or mobs in the personal chunk that aren't marked for removal. For movables this is an improvement on the old system in that it doesn't loop through turfs in range to get at their contents; on the downside, it means there may be potentially more movables to go through, but that's usually not a serious problem. Now when I tested Ishuri's deal that had the same stutter, I saw he had basically EVERY turf in a chunk being marked as interesting, and that was due to a bug. While I didn't profile the stutter, the only logical place it could have an impact is in step #3, when the chunks are iterated and the personal chunk is having new values allocated. However this can't simply be a case of too many malloc calls, because the personal chunk does not relinquish memory until it's freed. My feeling is that the insertion/search process may be taking too long. I have some ideas for speeding that process up that I can look into, so I'll do that today and see what I can come up with. | |
So there can be a lot of objects moving around all over the place and having their icons changed and being transformed and animated, sometimes using large sprites, sometimes quite a lot of them all at once. It didn't seem to change the stutter when I killed particles for testing but that was on 1331, maybe it would be a more obvious difference with 1332.