Using std::unordered_map as underlying container for object manager #142

New Issue

muellerr · 2020-07-14T13:37:38+02:00

muellerr commented

2020-07-14 13:37:38 +02:00

The object manager is an excellent tool to share software components.
I think it would be nice to access shared data sets for the new distributed data pools (I think raw access is nice and should be implemented for data sets as well) by registering them as system objects. Because that could lead to a higher number of system objects, I propose following change:

The underlying container of the ObjectManager should be a std:unordered_map . Contrary to the std::map
which is currently used, the unordered map uses a hashtable as the underlying container instead of a binary red-black tree. Therefore, it has lookup with constant complexity (O(1) instead of the already nice O(log n) of std::map). It uses more memory than the standard map, but I think that is ok. If this is a concern, I would suggest to select the underlying container as a ctor argument when initializing the object manager. What do you think? The map is intialized at software initialization, so the faster insertion operations of std::map are not needed.

The object manager is an excellent tool to share software components. I think it would be nice to access shared data sets for the new distributed data pools (I think raw access is nice and should be implemented for data sets as well) by registering them as system objects. Because that could lead to a higher number of system objects, I propose following change: The underlying container of the ObjectManager should be a `std:unordered_map` . Contrary to the `std::map` which is currently used, the unordered map uses a hashtable as the underlying container instead of a binary red-black tree. Therefore, it has lookup with constant complexity (O(1) instead of the already nice O(log n) of std::map). It uses more memory than the standard map, but I think that is ok. If this is a concern, I would suggest to select the underlying container as a ctor argument when initializing the object manager. What do you think? The map is intialized at software initialization, so the faster insertion operations of std::map are not needed.

muellerr added the

feature

label 2020-07-14 13:37:38 +02:00

gaisser commented

2020-10-27 15:07:45 +01:00

I don't think we have enough objects to cause a performance impact. The map is not expected to have more than order of 100 objects. Therefore, I see this as premature optimization.

gaisser closed this issue

2020-10-27 15:07:46 +01:00

Sign in to join this conversation.