I’m currently leaning from the PyROOT implementation in order to improve my Perl-ROOT wrapper. Clearly, I have a long way to go!
One tiny thing struck me as a little odd: The PyROOT TMemoryRegulator uses a std::map<TObject*, PyObject*> as an index to track all PyROOT objects. That means the map will become large, right? As far as I know, the std::map is an O(logN) container. This seems like a good case for using a hash-map which offers O(1) insertion and retrieval as an easy optimization. I don’t think there’s a hash-map in the STL in all implementations, though. There’s THashTable in ROOT, but I have no idea about it’s performance. I’ve been using a simple C (not C++) implementation for string hashing, but iit could be easily adapted to hash pointers instead: http://cpansearch.perl.org/src/SMUELLER/Class-XSAccessor-1.05/hash_table.h
yes, but the structure is supposed to be (haven’t measured) more compact in memory, too. OTOH I haven’t seen the TMemoryRegulator show up in CPU profiles: the conversion itself is where pretty much all of the time is spent.
It’s one of those things that need occasional revisiting to see whether the assumptions made when the code was written are still true.
Btw., design-wise: there’s another function to the memory regulator, which is to recycle python objects, so that there’s only one python object pointing to any one C++ object address. The reason of which is to implement unary operators, but it is also easier on the user.
thanks for your reply. Your rationale for choosing std::map makes complete sense. Premature optimization…
I haven’t thought about the implications of the map-structure on memory consumption and/or locality. Either way, I think std::map is some form of tree underneath and by extension likely not very compact in memory (I’m talking about locality not size). The while the hashmap keeps pointers in a contiguous array, the individual entries could be scattered all other the memory, so the difference is likely negligible.
Either way. Your argument still holds and the above considerations are purely academic. If, at some point, you decide to do some experimenting, have a look at http://github.com/tsee/SOOT/blob/master/SOOT/src/PtrTable.h, which is a slightly C++ified, but somewhat Perl centric (all the aTHX/pTHX threading context macros), variant of the hash table implementation I referred to earlier. Also, it was adapted to hashing pointers instead of strings.
having had the “pleasure” to program in C every once and a while, I’ve written my own hash tables probably a few times too many.
In addition, the python dictionary structure is a hashtable (albeit one optimized for starting out with a small number of entries), so I could reuse that one too if need be.
