Hashtable key = variable (possible?)

[Dr Super Good]

The world editor won't allow you to enter the same ID upon object creation.

It does not allow you to enter any ID upon object creation. That is a JNGP feature.

For spells, you usually only attach to two different types anyway: units and timers. And while collision is impossible that way, it's still a good practice to have a global table each:
For example, have a general "UNIT_HASH" containing data stored to GetHandleId(unit), then the childkeys indexed by the spell member identifiers (global constants that are unique for each variable in coded spells) and one more table "TIMER_HASH" for all dynamically created and destroyed timers (This is by far the more frequently used one of the two ... you rarely need to attach to units).

And how is this good practice? I would say better practice is to try and reuse the same hashtable as much as possible for short term storage.

 

[Zwiebelchen]

It does not allow you to enter any ID upon object creation. That is a JNGP feature.

Does that make the statement less true? JNGP doesn't let you enter the same ID twice and non-JNGP doesn't let you enter an ID at all. No matter what, the ID is unique.

And how is this good practice? I would say better practice is to try and reuse the same hashtable as much as possible for short term storage.

Because the unit hash will mostly have persistant data (i.e. custom defined stats, bonuses, upgrades, etc.), whereas the timer hash will mostly have temporary data.

It's just a minor speed optimization thing I do, as timer data tends to be more speed-critical than unit data (32 fps timers, etc.).

 

[Dr Super Good]

Does that make the statement less true?

It does not make it any less true, however it is misleading. It is just like saying that a car will not go any faster if given two bananas. The statement is still true but people might assume from it that given 1 or 3 bananas a car might go faster.

In this case they might assume that World Edit allows you to enter an ID upon object creation which it does not as that is a JNGP feature.

It's just a minor speed optimization thing I do, as timer data tends to be more speed-critical than unit data (32 fps timers, etc.).

Hashtable performance will only degrade once the bucket array reaches a high utilization factor, assuming equal data spread (proper hashes). If the bucket array is mostly empty then there will be no performance loss at all.

It is only really necessary to separate hashtables if the bucket array is reaching a high utilization rate. For example as it passes 0.7 or approaches 1. In real computer science the problem is solved by enlarging the bucket array however Blizzard did not provide natives for this.

The question that needs to be answered is what is the size of the hashtable bucket array? It is possible it automatically resizes up to a certain amount. Performance problems were only really noted after several thousand mappings. Is it a hashtable of hashtables, or does it just combine parent and child keys into single hash entries?