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(creat ion
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]

Re: Performance of Map

Sarath <CSarath@gmail. comwrites:

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(creat ion
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(FieldN ame name,float value){ fields[name]=value; }
inline float getField(FieldN ame 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(speed X,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.

--
__Pascal Bourguignon__

[Hendrik Schober]

Re: Performance of Map

Sarath wrote:

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]

Re: Performance of Map

On Oct 6, 9:00 pm, Hendrik Schober <spamt...@gmx.d ewrote:

Sarath wrote:

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]

Re: Performance of Map

Sarath wrote:

On Oct 6, 9:00 pm, Hendrik Schober <spamt...@gmx.d ewrote:

>Sarath wrote:

>>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(Ty pe_,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]

Re: Performance of Map

On Oct 6, 6:00 pm, Hendrik Schober <spamt...@gmx.d ewrote:

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.)

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34