[Re: [[CF-Devel] CPU and memory?]]

[Mark Wedel]

DAVID DELBECQ wrote:

>
     
      Ok, you say it requires a lot of changes because it is a problem of lots of
     
     >
     
      spells. If this is the case, this means you changed a lot of stuff from 0.97
     
     >
     
      version cause this version didn't lag and i don't think you made so heavily
     
     >
     
      changes.
     
     
 I looked, and don't see any changes between then and now which would
immediately change this behavioiur.  Note the lots of spell causing lag/high cpu
consumption is infinitely old (or at least as old as crossfire).   But
generally, it starts to require a fair number of spells before you hit the
threshold (although, to be honest, I don't know where the exact threshold is). 

>
     
     
     >
     
      Moreover, you speak about lots of spell on the same square. I have checked,
     
     >
     
      there are no more than 5 objects on a square (6 if i include my self, 7 with
     
     >
     
      the floor). The map, as i said, contain only 10 spellcaster, disposed so that
     
     >
     
      8 of them are hurting the player the same time, reducing number of spellcaster
     
     >
     
      is simply stupid.
     
     
 I would guess that the number of spells per square would need to be at least
20-30 before serious performance problems would get observed.  

>
     
     
     >
     
      3rd point, even if map could be smaller, with lesser spellcaster, don't forget
     
     >
     
      that level 80 players can cast more than 10 spells nearly at the same time,
     
     >
     
      linked on the same key in the client (e.g. cast 5 icestorm, 5 burnig hands, 5
     
     >
     
      holy word, 1 counterwall in the same key to do lots damages in a short time in
     
     >
     
      the arena.....). This cannot be prevented.
     
     
 Correct, and in fact that can cause performance issues.  comet/large fireball
are actually the worst examples, as they create a lot more objects for the one
cast.  But yes, the problem happens no matter who is casting the spells.

 However, generally players are more restained than most monsters are, who cast
things as fast as possible.  Players are probably more likely to try and limit
the number of spells to not be more than it really takes - otherrwise you burn
up mana and also increase the likelihood of incinerating the treasure you may
want.

>
     
     
     >
     
      At the end, i'll say this is not a problem for crossfire to be cpu consuming.
     
     >
     
      The problem is that it becomes also VERY laggy (can hang-up up to 5 seconds
     
     >
     
      when spellcasters become to cast).
     
     
 Its one in the same.  ITs laggy because the server is spending all its time
processing the spell objects.  It is probably worst when the spell casters first
come up because they have full mana and will unlease it as fast they can.

 One quick fix may be to increase the recovery time for high speed monsters
casting spells so they can't cast them quite as quickly (even delaying them a
few ticks may be enough, as its really the stacking of the spell objects on the
space that chew it up).

>
     
     
     >
     
      You say you are fixing bugs in crossfire for version 1.0 THIS clearly is a
     
     >
     
      bug, i recommend you to check closely at the cast cone code, it contains a lot
     
     >
     
      of useless assignements in a loop. (System does not seem laggy when casting
     
     >
     
      things other than cone!!). If you make some checks, you could also see the the
     
     >
     
      time consuming is done when spell casting, not when the spell spreads.
     
     
 I've done checking, and the time is when the spell is spreading.  IT happens
with fireballs and other ball spells.  Believe me, I have investigated this. 
The cost of creating the spell effect is small compared to inserting a spell
object on a space where there are 60 other objects, and we need to check all of
those to see if this spell may effect one of those or vice versa.  So inserting
the 61'st object requires 60 other object checks (each of them non trivial), and
to actually get up to that 60'th object has already required 1800+ such checks.

 Is this a bad bug?  Sure.  Should it be fixed for 1.0?  Would be nice, but
doing so would mean delaying 1.0 a long time - as said, the change to improve
that processing is non trivial, and is fairly integral - it really needs to be
pretty thoroughly tested.

 I will note that there are several public servers where this does noot
generally seem to be a problem.  And I have no illusions - there will be some
bugs in 1.0.  But a little while ago, it was decided that getting 1.0 out as
quick as reasonably possible was what was important, and not fixing everything
on the TODO list.