LOS Cache Prototype Idea
I wanted to throw this idea around as it can potentially save a lot of cpu on all the line of sight checks we do all the time. Rough calculations in velketor (using #aggrozone to put all mobs on me) show that under load I can save roughly up to 30% cpu usage. Idle was harder to calculate (takes time for the cpu to level out) but I did notice about up to a 10% cpu usage difference. Obviously this will change depending on what you set the millisecond value to (shorter at more cpu versus longer at less).
This adds two rules: by default it is off, you will have to enable it: RULE_BOOL ( Performance, LOSCacheEnabled, false ) Second the default cache entry value for now is kind of high, but for testing purposes it has been shown that cache entries stay alive long enough to be re-used, and if both npc/player don't move it saves additional calculations. However this does create a period that moving back and forth between a wall may be a bit inconsistent and in the end this value should probably be reduced. RULE_INT ( Performance, LOSCacheEntryMS, 3000 ) Pretty much what we do is get a LOS entry, put it into a map. When we CheckLOS again we see if the time at adding the entry + Performance:LOSCacheEntryMS against the current time, if current time is higher we automatically purge. If the entry is still 'new enough' we can check and see if their location is the same (just X,Y check for now, also thought maybe adding a precision here). If the location is the same for both mobs we cache the entry for the additional Performance:LOSCacheEntryMS. I also added some info to #checklos just for testing. It will display if there is a cached entry between Client->Mob or Mob->Client. Secondly it will track the hits (keep in mind that when we call the cache function it counts as a hit, the #checklos adds an additional hit for Client->Mob). Here is the code against the latest SVN: Code:
Index: common/ruletypes.h http://imgur.com/iBKUm |
Code:
LOSEntry ent = (LOSEntry)iter->second; You should also use a reference here as it avoids a copy, and then use the reference to update the values stored in the object rather than creating a new one and copying it over the existing one. |
I'll take those under consideration thanks. I typecast just to make it look cleaner frankly, but I agree with the update.
|
This is a bit cleaner.. The performance seems about the same, it may matter if the zones have 1000+ npc's.
Code:
Index: common/ruletypes.h |
I think the cache is a good idea, especially if there are many los checks being performed without the mobs moving, and as you've seen in your tests it does seem to be a performance win.
The only concern I have is that I don't see anything ever being removed from the cache. It'll get cleaned up in the destructor when a mob dies, but any other mob with entries pointing to the now destroyed mob won't go away. Do mobs regularly perform los checks on each other? I suppose the worry is that in a zone where many mobs are killed over and over but there are some that are never killed, then those caches would continue to grow over time as the entries that point to the dead mobs accumulate. The only way I can see to keep that from happening would be to tell every other mob to remove any entries pointing to a mob that is being destroyed from their cache. That would mean a potentially costly operation whenever a mob dies. An alternative could be to have a scheduled task on each that dumped entries that were very old, but then that will cause a periodic cpu spike if they all do it at the same time. Have you seen memory usage creeping up over time if you kill some mobs but not all of them? It might be worth logging out the size of each cache periodically for debugging purposes and see if they just grow forever on any mobs with long lifetimes. |
this CheckLosFN is called for quite a few things including aggro, friendly faction (mobs), spell casting, auto attack, etc. It would be possible to build it over time but difficult to consume large amounts of memory.
As you mentioned it would seem costly for a cleanup and I don't think that you would see the accumulation (we try to start re-using id's once we get up to 1500 in the Entity class). If anything -- it becoming a problem id say just every 5 minutes or something clear the map (dont bother checking the cache entries just flush it). |
All times are GMT -4. The time now is 08:54 AM. |
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.