Performance of Map

[Sarath]

Dear All,

I've a class which has lot of Get/Set functions. Since most of the
data members are of same type (e.g float), I'd like to implement it
with the help of lookup table ( probably will be using stl maps). The
code size will be considerably reduced if I use this method(by
avoiding set/get functions for each members). but I doubt on the
performance of stl map look up functionality. My program is doing some
intensive computations. Will this implementation creates any high
performance hit? I'm not really worried about the insertion(creation
of new keys) but looking to optimize the set/get of existing keys in
the map. Please provide your valuable suggestions.

-Sarat

 

[Pascal J. Bourguignon]

I've a class which has lot of Get/Set functions. Since most of the
data members are of same type (e.g float), I'd like to implement it
with the help of lookup table ( probably will be using stl maps). The
code size will be considerably reduced if I use this method(by
avoiding set/get functions for each members). but I doubt on the
performance of stl map look up functionality. My program is doing some
intensive computations. Will this implementation creates any high
performance hit? I'm not really worried about the insertion(creation
of new keys) but looking to optimize the set/get of existing keys in
the map. Please provide your valuable suggestions.

Code size would be even more reduced, and performance even better, if
you just made these fields public. Do you need to do any processing
when setting or getting these fields?


An alternative would be to use a vector, since this will be faster
than a map, and it could even be exactly as fast as public fields with
inline accessors:


class Rocket {
public:
enum FieldName {
speedX, speedY, speedZ,
accelX, accelY, accelZ,
FIELD_COUNT
};

inline void setField(FieldName name,float value){ fields[name]=value; }
inline float getField(FieldName name){ return(fields[name]); }

protected:
float fields[FIELD_COUNT];
};


Since most calls to setField or getField will be done with constant field names:

rocket->setField(speedX,0.4*c);

this should be compiled to the same code as if you had accessed a public field.
On the other hand, with such inline accessors, you can still add pre/post processing.

 

[Hendrik Schober]

Dear All,

I've a class which has lot of Get/Set functions. Since most of the
data members are of same type (e.g float), I'd like to implement it
with the help of lookup table ( probably will be using stl maps). The
code size will be considerably reduced if I use this method(by
avoiding set/get functions for each members). [...]

For one, this raises the question of why the class exists
in the first place. A class should support a certain
abstraction, and having all data fields effectively public
(which is what getters/setters usually come down to) doesn't
seem to come with a notable level of abstraction.
OTOH, if you don't want to revisit your design, make all
getters and setters 'inline'. That will keep the syntax the
way it is while effectively erasing the getters/setters
from the resulting executable.

-Sarat

Schobi

 

[Sarath]

Dear All,

I've a class which has lot of Get/Set functions. Since most of the
data members are of same type (e.g float), I'd like to implement it
with the help of lookup table ( probably will be using stl maps). The
code size will be considerably reduced if I use this method(by
avoiding set/get functions for each members). [...]

  For one, this raises the question of why the class exists
  in the first place. A class should support a certain
  abstraction, and having all data fields effectively public
  (which is what getters/setters usually come down to) doesn't
  seem to come with a notable level of abstraction.
  OTOH, if you don't want to revisit your design, make all
  getters and setters 'inline'. That will keep the syntax the
  way it is while effectively erasing the getters/setters
  from the resulting executable.

-Sarat

  Schobi

The reason is,
1. most of the functions return similar kind of values.
2. Have enormous number of attributes for the class.
3. No requirements are there to be implemented by derived classes.
4. Simply it's a data class.

 

[Hendrik Schober]

Dear All,
I've a class which has lot of Get/Set functions. Since most of the
data members are of same type (e.g float), I'd like to implement it
with the help of lookup table ( probably will be using stl maps). The
code size will be considerably reduced if I use this method(by
avoiding set/get functions for each members). [...]

For one, this raises the question of why the class exists
in the first place. A class should support a certain
abstraction, and having all data fields effectively public
(which is what getters/setters usually come down to) doesn't
seem to come with a notable level of abstraction.
OTOH, if you don't want to revisit your design, make all
getters and setters 'inline'. That will keep the syntax the
way it is while effectively erasing the getters/setters
from the resulting executable.

-Sarat

Schobi

The reason is,
1. most of the functions return similar kind of values.
2. Have enormous number of attributes for the class.
3. No requirements are there to be implemented by derived classes.
4. Simply it's a data class.

I can't judge your reasons to design your class the way you
did as I don't know your requirements. I can only point out
general ideas and principles.
Regarding inlining your functions: That would have the
advantage of compile-time safety over a map with lookups at
run-time. What about (ab)using macros like this
#define DEFINE_FIELD(Type_,Name_) \
private: Type_ Name_; \
public: Type_& get##Name_() {return Name_;} \
Type_ get##Name_() const {return Name_;}
void get##Name_(Type_ v) {Name_=v;}
for all your data fields?

Schobi

 

[James Kanze]

Sarath wrote:

I've a class which has lot of Get/Set functions. Since most
of the data members are of same type (e.g float), I'd like
to implement it with the help of lookup table ( probably
will be using stl maps). The code size will be considerably
reduced if I use this method(by avoiding set/get functions
for each members). [...]

For one, this raises the question of why the class exists
in the first place. A class should support a certain
abstraction, and having all data fields effectively public
(which is what getters/setters usually come down to) doesn't
seem to come with a notable level of abstraction.
OTOH, if you don't want to revisit your design, make all
getters and setters 'inline'. That will keep the syntax the
way it is while effectively erasing the getters/setters
from the resulting executable.

Some classes are mainly data recepiants; we've got similar
classes representing the data in the data basae, for example.

There are two "classical" solutions for this. The most general
is simply to use automatically generated code, and not worry
about the similarity of all of the functions. This has the
advantage that you can easily make them all virtual, and derive
and "intercept" certain setters, e.g. so that setting specific
values triggers other actions. The other alternative is to make
the entire thing dynamic, basically using something like
std::map< std::string, boost::variant< supported types > > as
the entire implementation, and looking up each variable by name.
It's also possible to mix the two solutions, using the generated
code for the actual data, but with an std::map< std::string,
Accessor* > to support symbolic access as well. (Obviously,
that map would be static, and also automatically generated.
This solution becomes very interesting when you start throwing
in additional functionality like serialization or reading and
writing from a data base using SQL.)