Code optimizations

[HunabKu]

I create this subject to list coding optimization we can use.

[HunabKu]

If/Else vs Switch performance comparaison

After many internet searches and personnal tests, il can say you :

- If/Else is faster for 1-5 elements
- Switch is faster for 6 and more elements because it use lookup table/hash list.

[Leodagan]

This is fine optimizations for critical real-time application

But we should not sacrifice Code readability, or upgrade easiness, and global project accessibility for performance improvements on DOL except in some critical area...

If DOL needed performance critical code quality it wouldn't use Managed Framework to begin with, the flexibility of C# and the .NET framework are needed to reduce work from community and allow for wide improvements even by people who lacks development knowledge.

If you look at GameTimer Class that tries to mimic some "Assembly" low-level optimization on timer scheduling you'll see that mostly no-one can change anything in there without understanding the "high-level" algorithm.

The same goes for GameObject allocation in Region/Zone, which is really hard to read and doesn't even implement full-fledged "known" Geometry Algorithms (Nearest Neighbor with Binary Tree)

But the fact that these two aspects of DOL are intensively used in most part of the Server make them "Critical Code Area" that allows high performance gain for some "unreadable" Code...

Other Area like Game Rules, or World Events don't need such optimizations, and should be as simple and readable as possible to allow for easy customization and understanding code trace when Players encounter weird behavior in-Game.

There are lot of optimizations that can be used to improve DOL, the most obvious one are around "Collections", Boxing Collections like ArrayList or HybridDictionary should be avoided, these are always meant to hold some amount of data that could greatly take advantage of better Generic Collections like List<T> or Dictionary<K, V>, Other Collections that aren't meant to be modified should be handled as Array (Cast as ICollection<T> for overrides) avoiding using List<T> which has a big overhead...

But even this kind of optimizations sometimes bring code complexity : "Lists" have a lot of useful tools even when they are not meant to be modified (Searching Methods, Subset extracting, etc), "Arrays" lack these methods even if LINQ library can do the trick (but I'm not sure every contributor is comfortable with LINQ...), and building a "List" to finally return with ToArray() is unproductive !


I would prefer that most DOL code "obey" Object-Oriented Logic, not trying to handle Special Case in Objects that aren't meant to do this work, GamePlayer Class being over 10 000 Line is something pretty bad for example, last time I found some special Spell Method in GamePlayer Casting Area that should be in "SpellHandler" Class, other Example in SpellHandler AoE targeting we have code populating GameNPC Brain AggroTable that shouldn't be handled here !

Object-Oriented is meant to Allow group of Developers to work on different parts of a Project without breaking each other patch, this would allow easier DOL improvements, aside from performance improvements...

[HunabKu]

Thanks for this informations Leodagan !

[Dinberg]

But we should not sacrifice Code readability, or upgrade easiness, and global project accessibility for performance improvements on DOL except in some critical area...

Completely support this, please don't replace switches with if/elseif because it hurts readability imo

[Graveen]

A big deal is to track frameworks improvements and to use them because they generally worths it:
- use generics - List<T>, Dictionary<T> (thanks to Darwin & Leodagan, there should not be a lot)
- LINQ

And use framework class instead of recoding them :p

[HunabKu]

Thanks for these good practices informations

[Nydirac]

A thing i remember from the dol of 2007 was the pretty bad use of locking mechanisms for all the collections, it was pretty sparse of shared locks/update locks and always used simple locks (exclusive) for everything...

[Leodagan]

There are some improvement coming around this...

I can't track all code using bad lock, and it can be pretty hard to guess what the code is meant to do and prevent any feature breaking change !

... But I made some simple Collection with Read/Write access using Slim Locks, this mean there is a shared lock for reading, and a unique lock for writing, I also made iterator of these collections return snapshot of current items to allow for lock free reading

They are pretty useful for Game Object Members that need to be secured from Multi thread Access while holding only small amount of objects (Skills Collections for example, or XPGainer/Attackers Collection), but there is some special use case to prevent race conditions (you can't check if a specific value is present then get this value, you have to use some of the special Method TryGetValue() to make it in one call and prevent a race condition where the item got deleted between the exist check and the get Method)

For most other part of DOL I just Update the exclusive lock() mechanisms that most of the time try to lock a collection for a global object lock using a private/protected "lock object", this at least prevent errors like locking a "Null" Collection... but it doesn't improve performances...

On the same purpose I also remove all the Shared Lock where I can find some other method like getting a "locked" collection copy from the object itself, but this can remove a lot of safety around object interaction :

Locking Player Inventory with a Shared lock for a transaction prevent any other object from accessing Inventory and must wait for the whole transaction to finish before getting an exclusive lock, this is really useful to prevent any race condition between modifications to Inventory or even other game mechanisms that need some Item Value, if you use a "lock free" collection around here, the transaction method will iterate a copy and will have to use specific methods for checking object still exists before modifying anything, this is pretty much harder to code and it can bring a lot of errors !

Hopefully DOL Doesn't have so much thread concurrency, everything is kind of handled in a single thread manner using the game timer scheduling.

[Nydirac]

Yep it's a pain in the XXXX, i had started something similar years ago (custom object class with a readonly/exclusive mode), i'm sorry that you have to redo everything (i think its simpler to redo everything in the new code than to reuse something +8 years old).



PS: Anyone know why there are no check for distance / permission to open doors? it's like 5 lines of code...
EDIT: And why there is no warning to the player that a quest has only *language* available and not english ( i found XXX quests only in french in genesis shard... )

[HunabKu]

EDIT: And why there is no warning to the player that a quest has only *language* available and not english ( i found XXX quests only in french in genesis shard... )

I think is because the majority of the Genesis team is French.