Quote:Original post by Toolmaker
However, why exactly are you storing your quads with an ID? Wouldn't it be more efficient to just check if an object instance is already in the list? And on dictionaries, why not just calculate the hash code? The hash isn't used to store the object by, just as a way to quickly index it.

Toolmaker

QFE. A HashSet might even be appropriate here, though I'm naively skeptical of the need for a pool in the first place.

(If ID counting is still needed after previous comments)

Personally, I would keep it simple and minimalistic, and implement a small ID-counter that is atomically incremented (read: it shall be thread safe) upon each generateId() call.


So, if you need a global id-counter for each class:



Or if you want to have local id-counters:



And if you want to load the counter from some file, then call some function that loads a saved id from some file, instead of intializing it to zero.

Quote:Original post by Spa8nky
Thanks very much for all your help with this one guys.

Using a GUID has also solved the query I had in my previous thread.

How do you use the GUIDs? I think if you use them in some acceleration structure (e.g. a complete node in a Kd-tree is only 8 bytes in ray tracing *) or for groups of vertices, they waste way too much memory; I think 16 bytes per single ID, when your ID is only used within your application, is total exaggeration.

Or is it somehow mandatory to identify your data in a solar system wide pool? I seriously mean it; do you know that when you lay down each possible 64bit value in a row, with a sub-millimeter distance (afair 0.002 cm), you'll already range the whole solar system? With 65 bit you double that range, 66 bits is 4x the range, et cetera.

Can you guarantee that the number of unique id's never exceeds 18,446,744,073,709,551,616 (==18,446,744,073,709 million == 18,446 million billion)? Use a uint64 (half of a GUID). Never exceeds 4,294,967,296? Use a uint32 (1/4 of a GUID). Never exceeds 65,536? You are lucky, you can use a uint16 (1/8 of a GUID).

Not specifically addressed at you, just throwing that in: Having way more powerful machines these days, nobody has to wonder about why applications still seem to crawl like back in the day, when so many application developers are wasting so much bandwidth, computing time, and memory.

*: I once crunched a special Kd-tree node into 4 bytes (afair) to store 130 million triangles in a real time ray tracer, in less then 512 MiB of main memory. Using another size optimisation, 2 byte nodes would have been possible.