Jump to content

lag investigation thread


Recommended Posts

Hey all,

mostly out of curiosity I tried to simulate a few different scenarios to find out what parts of the code contribute the most to the lag and should be considered first for future optimizations.

As this may or may not be depending on the system the game is played on, I will post the replays here, so that interested people can see if it is the same for them.

[EDIT: I updated the videos, but I didn't include all replays yet]

lag_test_replays.zip

All this was tested with svn rev 25963 and I tried to have between 500 and 600 units for each test.

TLDR: Most of the things I tested worked better than I thought, but the main problem on my system seems to be unit overkill, which happens mostly with ranged unit attack

_____________________________________________________________________________________________

 

1st test: long range pathfinding with one type of unit

result for me: not that bad actually very little lag 1/10

----------------------------------------------------

2nd test: long range pathfinding with multiple unit types (graphic influence)

result for me: also good, very little lag 1/10

----------------------------------------------------

test 3: melee combat with 600 units |

result for me: noticeable lag 7/10

----------------------------------------------------

test 4: ranged combat with 600 units

result for me: without having a good measurement I would say the most lag so far 10/10

----------------------------------------------------

test 5: ranged combat with 600 units but emphasis on the projectile calculation

result for me: nearly no lag 1/10

----------------------------------------------------

test 6: ranged combat with 600 units but emphasis on the overkill factor

result for me: huge lag 10/10

----------------------------------------------------

test 7: gathering & short pathfinding

result for me: nearly no lag 1/10

----------------------------------------------------

test 8: BuildingAI

result for me: nothing 0/10

 

Edited by maroder
  • Like 4
Link to comment
Share on other sites

I updated the post

What I would conclude from all that (no guarantee on correctness) is that the main reason for lag (at least for me) is the overkill factor.

So the engine seems to dislike it if the health of a unit is so much reduced that it dies, but there are still other attacks incoming, which are now targeting an entity that is already dead. And this happens much more often when ranged units attack vs when melee units attack.

All other parts, be it graphics, short and long range pathfinder ect, seem not too bad from these tests.

Edited by maroder
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

probably because they actually deal more attacks. also there's the random number generator for the spread and the rendering of the projectiles.

In any case, the attack/damage routines are those that suck the most resources it seems.

Link to comment
Share on other sites

Yeah, rewriting all that seems like a huge project, so I get that part of the argument, but personally I don't think the modability factor should play a role here (and I like to make mods).

The question is who wants to mod a game that is not functioning correctly? not doing optimization only because someday someone might want to change it seems to me like a bad tradeoff. If there are ways to optimize the javascript part that should of course be preferred, but if the only way to fix that would be to reduce some of the modability, then that is the sacrifice that has to be done (imo).

Edited by maroder
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

And the other question is: would it really need a complete rewrite? From what I saw I would say that that the problematic part is the unit death / attacking combination and not all of the attacking routine. But I also would really like to hear what conclusions other people draw from the videos :)

Link to comment
Share on other sites

Aside from re-writing code, one could still implement changes to reduce overkill (and therefore, lag) such as attack-ground. It would still be the player's decision whether or not to use attack-ground, but it would also be more effective in large battles due to less overkill.

However, this does looks laggy on its own right, maybe it just appears bad since its shown in 0.5x speed.

Attack-ground:

 

Link to comment
Share on other sites

35 minutes ago, maroder said:

Yeah, rewriting all that seems like a huge project, so I get that part of the argument, but personally I don't think the modability factor should play a role here (and I like to make mods).

The question is who wants to mod a game that is not functioning correctly? not doing optimization only because someday someone might want to change it seems to me like a bad tradeoff. If there are ways to optimize the javascript part that should of course be preferred, but if the only way to fix that would be to reduce some of the modability, then that is the sacrifice that has to be done (imo).

The problem is that attack.js is linked to so many components that you would have to freeze them too (eg, health resistance unitai and possibly others) rendering the game a lot less moddable not just a bit. I'm hoping there is a better alternative but mayber there isn't.

 

What's slow when Units are dying are the onownership messages and another one. You can see it pretty clearly using profiler2. Making the messages faster might help a lot. Could even be threaded maybe.

 

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...