question about timers/hastables

[Cetacean]

Basically, I was wondering if there is any reason to flush the children of a timer handle (after the handler function finishes) when using a timer recycler stack. It seems like it's just extra overhead, right?

Somewhat relatedly, would it also hold true that ideally you only want to flush the children of a given unit handle once (when it leaves the map)?

 

[Almia]

I think it can't flush the datas stored in the unit handle.
But actually,you can't retrieve the stored datas from it.

 

[WaterKnight]

When you recycle objects, you would normally expect them to be fresh. The stored information does not magically disappear from the hashtable and is not connected to the handles but to their ids. So if there is a new object with the id of an old, destroyed one, which is especially the case when you recycle stuff, it will inherit the old data. And otherwise, if you keep fetching new unique ids to avoid collision, this will pose memory leaks.

It is another story for the case that the objects are statically programmed, will therefore never release its id and may not have to change their assigned values.

 

[Cetacean]

Cool, that seems to confirm what I was thinking, but let me run through it again just to make sure.

My understanding is that when you pull the timer out of the recycler, it will have the same id ( i.e. GetHandleId(t) ) as the last time that particular timer was used (unless there are no timers left in the recycler stack, in which case it would be a fresh id). This is why I was wondering if it's worth it to flush the children of the timer id in the handler hashtable (just simple usage for passing 1 or 2 values). Since you're mostly reusing the same range of timer ids over and over again, it seems like it should be fine to never flush them, assuming you're not worried about collision.

Would this sort of usage create memory leaks?

 

[WaterKnight]

If you do not have to read their data before setting them again, the flushing can be omitted. Theoretically, it does not create memory leaks, as the same timers with their hashtable entries can be reached over and over again but depending on need, you may have reserved such an amount of timers before you would never require again. Not leaking does not mean that it does not draw its resources.

I do not know your recycler but normally you would wrap it into an own type and having it grant an array-able id via library. Then you would not need to use hashtable within your execution scope. Moreover, practically, you only assign the struct instance to the timer it belongs to. This can be provided via the library as well.

 

[Zwiebelchen]

If you overwrite all the data inside a given ID on the table properly, there is no need to flush it first.

However, it's a very bad programming practice, as it is prone to cause bugs.
It's basicly the same as not initiating a variable. In most programming languages, you do not need to initialize a global variable. If you assign a value to it before retrieving, this is totally fine, but if you for some reason (possible cases you haven't thought about when programming, like the user being dumb and inserting invalid data) do not assign a new value, you have access to the old inherited data.

Not only does flushing improve the internal structure and readability of your code (if someone else or your future-self in two years reads the code, he might be confused about the fact, as it implies that those variables are still used somewhere else), it also avoids bugs with table reads of not initialized data.

 

[Cetacean]

Not leaking does not mean that it does not draw its resources.

By this do you mean that while technically not a leak, it still might be occupying memory, drawing CPU cycles, or just making that particular hashtable slower in general? If so, does this sort of thing (when taking place on a modest scale) have a noticeable impact on the performance of modern PCs?

@Zwiebelchen

Hmm, that's interesting to note. It just seems inefficient to me to be flushing the hashtable children of the timer id every single time they expire, especially when there's lots of timers firing within a short span. Maybe I should pass that data with an array[convertedHandleId] instead? Or, is the performance impact of the hashtable negligible anyways?

 

[edo494]

well yea, because data in hashtable takes a place in your RAM, not flushing the data will make them stay at your RAM, and if you never come to the same HandleId ever again, it is permament leak(unless you flush the whole hashtable)

I would just flush the child hashtable only when Im done with the timer(right before you call DestroyTimer(..) or when you do something like ReleaseTimer(..) in case you are using some recycler for timers such as TimerUtils by Vex or Mag)

Also keep in mind that the more items are kept in hashtable