deserialization optimization
I am an old runuo guy, it has been almost two year that I havent looked runuo scripts.
today, I had a chance to overlook some core scripts..
While loading the world, there is an issue with hashtables..
A hashtable's size is never the same as the count of objects in itself.
Approximately, the max number of objects would be the half of the size..
(I checked MSDN for more info, the most efficient ratio is 0.72 which is default)
Consider the following situation:
-lets say you created a hashtable with the initial capacity 100.
-insert 72 items
-if you insert one more item, what will happen?
If you try to insert one more item, before it's hashed and located, the following occurs:
-hashtable is expanded (almost doubled)
-each item in hashtable is rehashed and relocated..
So, obviously this is an important overhead..
To resolve the problem, the initial capacity of the hashtables should be double of the item/mobile count, so that loading factor would be 0.5
The less loading factor is , the more faster loading will be..(less collision, faster lookup)
0.5 is fine almost anytime. Also it gives some flexibility for runtime.
It is possible to choose different loading factors for items and mobiles. The number of mobiles could be considered as more stable than the number of items, so you can choose a loading factor like 0.6 . It is really a trade-off between speed and memory, decision is up to you..
the more info about hashtables
Anyway, the current implementation should be changed whatever loading factor you choose..
I hope RunUO team consider my suggestion
I am an old runuo guy, it has been almost two year that I havent looked runuo scripts.
today, I had a chance to overlook some core scripts..
While loading the world, there is an issue with hashtables..
A hashtable's size is never the same as the count of objects in itself.
Approximately, the max number of objects would be the half of the size..
(I checked MSDN for more info, the most efficient ratio is 0.72 which is default)
Consider the following situation:
-lets say you created a hashtable with the initial capacity 100.
-insert 72 items
-if you insert one more item, what will happen?
If you try to insert one more item, before it's hashed and located, the following occurs:
-hashtable is expanded (almost doubled)
-each item in hashtable is rehashed and relocated..
So, obviously this is an important overhead..
To resolve the problem, the initial capacity of the hashtables should be double of the item/mobile count, so that loading factor would be 0.5
The less loading factor is , the more faster loading will be..(less collision, faster lookup)
0.5 is fine almost anytime. Also it gives some flexibility for runtime.
It is possible to choose different loading factors for items and mobiles. The number of mobiles could be considered as more stable than the number of items, so you can choose a loading factor like 0.6 . It is really a trade-off between speed and memory, decision is up to you..
the more info about hashtables
Anyway, the current implementation should be changed whatever loading factor you choose..
I hope RunUO team consider my suggestion