objects[] array code review
Warning! This is the old Hercules bugtracker archive, and may not reflect the current state of Hercules. The current bugtracker is on GitHub Issues.
Issue information
Issue ID
#2559
Status
Fixed
Severity
None
Started
Hercules Elf Bot
Dec 21, 2008 3:30
Last Post
Hercules Elf Bot
Dec 21, 2008 3:30
Confirmation
Hercules Elf Bot - Dec 21, 2008 3:30
Originally posted by [b]theultramage[/b]
http://www.eathena.ws/board/index.php?autocom=bugtracker&showbug=2559
An issue was mentioned on irc where increasing MAX_FLOORITEM past 2M messed up player timers. The reason was that the array became so large that its id interval overlapped the player object id interval, and so player objects were handled as if they were flooritem objects. This lead me to examine the code to see what it actually is about.
So. There is a global objects[] array, which holds bl pointers. It acts as a cache for id_db, recording objects that need their id generated ad-hoc. Currently it's these: chatroom objects, land skill unit objecst, and items on the ground. There is a function to add a new object (and generate an id), to delete an existing object, and to iterate over all objects of a certain type.
The only benefit I found was is to speed up the search for a free id. If the array wasn't there, the search would take O(log n) instead of O(1). But this is only theoretical - in practice the benefit may be negligible or none at all.
On the other hand, the downsides are numerous
- 2MB of allocated memory (default), even if most of it is unused.
- fixed limit of ids; increasing limit means increasing mem usage.
- uglifies code quite a bit; code is hard to read and debug.
To evaluate the usefulness of the objects array, I have written a small patch (attached to this post). It adds the gmcommand '@profile', which simply resets the profiler when it's called the first time, and writes log/profile.log when it's called the second time. The output is a frequency distribution for the number of attempts required to find a free id.
I'd like to see some snapshots made with this thing - say, with 100 players, 250 players and 1000 players, and during normal time and woe time (1 hour each). That should give a decent idea of what's going on.
profiling_objects.diff ( 2.04K ) Number of downloads: 52
http://www.eathena.ws/board/index.php?autocom=bugtracker&showbug=2559
An issue was mentioned on irc where increasing MAX_FLOORITEM past 2M messed up player timers. The reason was that the array became so large that its id interval overlapped the player object id interval, and so player objects were handled as if they were flooritem objects. This lead me to examine the code to see what it actually is about.
So. There is a global objects[] array, which holds bl pointers. It acts as a cache for id_db, recording objects that need their id generated ad-hoc. Currently it's these: chatroom objects, land skill unit objecst, and items on the ground. There is a function to add a new object (and generate an id), to delete an existing object, and to iterate over all objects of a certain type.
The only benefit I found was is to speed up the search for a free id. If the array wasn't there, the search would take O(log n) instead of O(1). But this is only theoretical - in practice the benefit may be negligible or none at all.
On the other hand, the downsides are numerous
- 2MB of allocated memory (default), even if most of it is unused.
- fixed limit of ids; increasing limit means increasing mem usage.
- uglifies code quite a bit; code is hard to read and debug.
To evaluate the usefulness of the objects array, I have written a small patch (attached to this post). It adds the gmcommand '@profile', which simply resets the profiler when it's called the first time, and writes log/profile.log when it's called the second time. The output is a frequency distribution for the number of attempts required to find a free id.
I'd like to see some snapshots made with this thing - say, with 100 players, 250 players and 1000 players, and during normal time and woe time (1 hour each). That should give a decent idea of what's going on.