Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Performance vs. Design (long)

Reply
Thread Tools

Performance vs. Design (long)

 
 
Case
Guest
Posts: n/a
 
      06-24-2004
I've had some discussions with colleagues about the
API of a module for sending/receiving messages on a
network connection.

On both ends are different applications, each having
their own internal way of storing the data which has
to be communicated (using a common data protocol).

I proposed to use a common interface, having the face
of the network data protocol (XYZ). Many fields in the
protocol message are optional. I proposed to use a
bit-field structure. To prevent one extra copy of
large chucks of data, I proposed to use pointers.

typedef struct
{
unsigned int number1 : 1;
unsigned int number2 : 1;
unsigned int much_data : 8; /* > 0 means length */
} XYZ_ind;

typedef struct
{
int number1;
int number2;
char *much_data;
XYX_ind_t ind;
} XYZ_data_t;

void XYZ_send(XYZ_data_t *data); /* encodes, then sends */

The receiving side uses a callback, with similar prototype.

Both sides will now have to convert their own internal format
to a XYZ_data_t structure. This creates a clea[n|r] interface,
making the XYZ module independent of either side.


The 'opposing' idea is to not specify a common interface for
all users. So, no XYZ_data_t. Instead of one shared XYZ_send(),
there will be two: A_send(A_data_t *) and B_send(B_data *).
Instead of one module, there will be three.

The only advantage above having a real interface, is performance:
no conversion between internal format to XYZ_data_t (which is not
much more than assignments). The A_send() and B_send() will both
encode the message in their own way, and right away.


Yes, we are working on time-critical stuff, but I have the feeling
that this second approach falls in the 97% of the 'premature opti-
mization, being the root of all evil'. I estimated that the clean
interface may add about 1/1000 to the execution time.

Any thoughts on this issue?

Case

 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      06-24-2004
Case wrote:
>
> I've had some discussions with colleagues about the
> API of a module for sending/receiving messages on a
> network connection.
>
> On both ends are different applications, each having
> their own internal way of storing the data which has
> to be communicated (using a common data protocol).
>
> I proposed to use a common interface, having the face
> of the network data protocol (XYZ). Many fields in the
> protocol message are optional. I proposed to use a
> bit-field structure. To prevent one extra copy of
> large chucks of data, I proposed to use pointers.
>
> typedef struct
> {
> unsigned int number1 : 1;
> unsigned int number2 : 1;
> unsigned int much_data : 8; /* > 0 means length */
> } XYZ_ind;
>

.... snip ...
> mization, being the root of all evil'. I estimated that the
> clean interface may add about 1/1000 to the execution time.
>
> Any thoughts on this issue?


What clean interface? One bit numbers don't carry much
information, and I have a tough time envisioning much_data crammed
into 8 bits. Also, bit fields are inherently non-portable, even
between generations of the same compiler on the same hardware.

--
Chuck F ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!


 
Reply With Quote
 
 
 
 
Dan Pop
Guest
Posts: n/a
 
      06-24-2004
In <(E-Mail Removed)> CBFalconer <(E-Mail Removed)> writes:

>into 8 bits. Also, bit fields are inherently non-portable, even

^^^^
>between generations of the same compiler on the same hardware.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^
Care to provide a couple of concrete examples? I have a hard time
imagining an implementor screwing his user base...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Case
Guest
Posts: n/a
 
      06-24-2004
CBFalconer wrote:
> Case wrote:
>
>>I've had some discussions with colleagues about the
>>API of a module for sending/receiving messages on a
>>network connection.
>>
>>On both ends are different applications, each having
>>their own internal way of storing the data which has
>>to be communicated (using a common data protocol).
>>
>>I proposed to use a common interface, having the face
>>of the network data protocol (XYZ). Many fields in the
>>protocol message are optional. I proposed to use a
>>bit-field structure. To prevent one extra copy of
>>large chucks of data, I proposed to use pointers.
>>
>>typedef struct
>>{
>> unsigned int number1 : 1;
>> unsigned int number2 : 1;
>> unsigned int much_data : 8; /* > 0 means length */
>>} XYZ_ind;
>>

>
> ... snip ...
>
>>mization, being the root of all evil'. I estimated that the
>>clean interface may add about 1/1000 to the execution time.
>>
>>Any thoughts on this issue?

>
>
> What clean interface? One bit numbers don't carry much
> information, and I have a tough time envisioning much_data crammed
> into 8 bits. Also, bit fields are inherently non-portable, even
> between generations of the same compiler on the same hardware.
>


XYZ_ind contains presence/length indicators for the actual
structure members, which have the same name.

Case

 
Reply With Quote
 
Alan Balmer
Guest
Posts: n/a
 
      06-24-2004
On Thu, 24 Jun 2004 13:26:24 +0200, Case <(E-Mail Removed)> wrote:

>I've had some discussions with colleagues about the
>API of a module for sending/receiving messages on a
>network connection.
>
>On both ends are different applications, each having
>their own internal way of storing the data which has
>to be communicated (using a common data protocol).
>
>I proposed to use a common interface, having the face
>of the network data protocol (XYZ). Many fields in the
>protocol message are optional. I proposed to use a
>bit-field structure. To prevent one extra copy of
>large chucks of data, I proposed to use pointers.
>
>typedef struct
>{
> unsigned int number1 : 1;
> unsigned int number2 : 1;
> unsigned int much_data : 8; /* > 0 means length */
>} XYZ_ind;
>
>typedef struct
>{
> int number1;
> int number2;
> char *much_data;
> XYX_ind_t ind;
>} XYZ_data_t;
>
>void XYZ_send(XYZ_data_t *data); /* encodes, then sends */
>

I wouldn't use the bit fields. Aside from their portability problems,
they will probably be less efficient - the transmission time saved
will be less than the additional processing time.
[OT]
Communications protocols typically send the message size first, making
it easy to grab the entire message in two reads, and making it easy to
send variable size messages, or change your mind about the message
size.
I assume that your send routine is sending the data that much_data
points to, not the pointer itself.

>The receiving side uses a callback, with similar prototype.
>
>Both sides will now have to convert their own internal format
>to a XYZ_data_t structure. This creates a clea[n|r] interface,
>making the XYZ module independent of either side.
>
>
>The 'opposing' idea is to not specify a common interface for
>all users. So, no XYZ_data_t. Instead of one shared XYZ_send(),
>there will be two: A_send(A_data_t *) and B_send(B_data *).
>Instead of one module, there will be three.
>
>The only advantage above having a real interface, is performance:
>no conversion between internal format to XYZ_data_t (which is not
>much more than assignments). The A_send() and B_send() will both
>encode the message in their own way, and right away.
>
>
>Yes, we are working on time-critical stuff, but I have the feeling
>that this second approach falls in the 97% of the 'premature opti-
>mization, being the root of all evil'. I estimated that the clean
>interface may add about 1/1000 to the execution time.
>
>Any thoughts on this issue?
>
>Case


--
Al Balmer
Balmer Consulting
(E-Mail Removed)
 
Reply With Quote
 
Case -
Guest
Posts: n/a
 
      06-24-2004
Alan Balmer wrote:
> On Thu, 24 Jun 2004 13:26:24 +0200, Case <(E-Mail Removed)> wrote:
>>I've had some discussions with colleagues about the
>>API of a module for sending/receiving messages on a
>>network connection.
>>
>>On both ends are different applications, each having
>>their own internal way of storing the data which has
>>to be communicated (using a common data protocol).
>>
>>I proposed to use a common interface, having the face
>>of the network data protocol (XYZ). Many fields in the
>>protocol message are optional. I proposed to use a
>>bit-field structure. To prevent one extra copy of
>>large chucks of data, I proposed to use pointers.
>>
>>typedef struct
>>{
>> unsigned int number1 : 1;
>> unsigned int number2 : 1;
>> unsigned int much_data : 8; /* > 0 means length */
>>} XYZ_ind;
>>
>>typedef struct
>>{
>> int number1;
>> int number2;
>> char *much_data;
>> XYX_ind_t ind;
>>} XYZ_data_t;
>>
>>void XYZ_send(XYZ_data_t *data); /* encodes, then sends */
>>

>
> I wouldn't use the bit fields. Aside from their portability problems,
> they will probably be less efficient - the transmission time saved
> will be less than the additional processing time.
> [OT]
> Communications protocols typically send the message size first, making
> it easy to grab the entire message in two reads, and making it easy to
> send variable size messages, or change your mind about the message
> size.
> I assume that your send routine is sending the data that much_data
> points to, not the pointer itself.


I think I am so much in this design, that I forgot to
mention essentials for understanding it for outsiders.
Sorry about this people. I don't send the XYZ_ind_t
field, which is only used to indicate which fields of
the actual data in the rest of the struct needs to be
send.

I decided to use bit-fields because of their small size
compared to using a set of booleans (i.e., int's). This
is because I need to initializa all indicators to 0;
again a matter of performance. In my real aplication
there are about 40 optional fields, of which less than
half are actually being used on average.

In my view, bit-fields are not that performance demanding
compared to using int's set to 0 or 1. What do you think?

Case

 
Reply With Quote
 
Arthur J. O'Dwyer
Guest
Posts: n/a
 
      06-24-2004

On Thu, 24 Jun 2004, Case - wrote:
> >>
> >>typedef struct
> >>{
> >> unsigned int number1 : 1;
> >> unsigned int number2 : 1;
> >> unsigned int much_data : 8; /* > 0 means length */
> >>} XYZ_ind;

> >
> > I wouldn't use the bit fields.

[...]
> I decided to use bit-fields because of their small size
> compared to using a set of booleans (i.e., int's). This
> is because I need to initializa all indicators to 0;
> again a matter of performance. In my real aplication
> there are about 40 optional fields, of which less than
> half are actually being used on average.
>
> In my view, bit-fields are not that performance demanding
> compared to using int's set to 0 or 1. What do you think?


I would use a set of flags, myself.

struct XYZ_ind
{
unsigned long fields;
int much_data;
};

#define FIELD_NUMBER1 0x0001
#define FIELD_NUMBER2 0x0002
#define FIELD_FOO 0x0004
[...]

Then instead of 'if (x->number1)' you would write
'if (x->fields & FIELD_NUMBER1)'. Extra typing, but guaranteed to
be small (unlike bit-fields, AFAIK) and pretty fast in practice.
And bitwise flags are IMHO less obscure than bit-fields, although
you could argue both ways, I suppose.

And of course initializing all your flags to zero becomes a single
assignment, instead of 32 assignments. That's a plus.

If you need more than 32 flags, just add a 'fields2' member to
your struct. If it sounds reasonable, you might segregate the
flags by purpose, e.g.

unsigned int header_flags;
unsigned int encoding_flags;
unsigned int message_flags;
unsigned int network_flags;
[...]

HTH,
-Arthur
 
Reply With Quote
 
Christian Bau
Guest
Posts: n/a
 
      06-24-2004
In article <40db244b$0$62399$(E-Mail Removed) >,
Case - <(E-Mail Removed)> wrote:

> I decided to use bit-fields because of their small size
> compared to using a set of booleans (i.e., int's). This
> is because I need to initializa all indicators to 0;
> again a matter of performance. In my real aplication
> there are about 40 optional fields, of which less than
> half are actually being used on average.
>
> In my view, bit-fields are not that performance demanding
> compared to using int's set to 0 or 1. What do you think?


Bit fields are inherently non-portable. To maximise portability, send a
sequence of unsigned char values with values from 0 to 255. Instead of
bit-fields, use the eight bits in the unsigned char.

Otherwise, at the very least you will end up having to define your
structs in different ways depending on the compiler.
 
Reply With Quote
 
Travis Breitkreutz
Guest
Posts: n/a
 
      06-25-2004
"Case -" <(E-Mail Removed)> wrote in message
news:40db244b$0$62399$(E-Mail Removed) i.nl...
> Alan Balmer wrote:
> > On Thu, 24 Jun 2004 13:26:24 +0200, Case <(E-Mail Removed)> wrote:
> >>I've had some discussions with colleagues about the
> >>API of a module for sending/receiving messages on a
> >>network connection.
> >>
> >>On both ends are different applications, each having
> >>their own internal way of storing the data which has
> >>to be communicated (using a common data protocol).
> >>
> >>I proposed to use a common interface, having the face
> >>of the network data protocol (XYZ). Many fields in the
> >>protocol message are optional. I proposed to use a
> >>bit-field structure. To prevent one extra copy of
> >>large chucks of data, I proposed to use pointers.
> >>
> >>typedef struct
> >>{
> >> unsigned int number1 : 1;
> >> unsigned int number2 : 1;
> >> unsigned int much_data : 8; /* > 0 means length */
> >>} XYZ_ind;
> >>
> >>typedef struct
> >>{
> >> int number1;
> >> int number2;
> >> char *much_data;
> >> XYX_ind_t ind;
> >>} XYZ_data_t;
> >>
> >>void XYZ_send(XYZ_data_t *data); /* encodes, then sends */
> >>

> >
> > I wouldn't use the bit fields. Aside from their portability

problems,
> > they will probably be less efficient - the transmission time saved
> > will be less than the additional processing time.
> > [OT]
> > Communications protocols typically send the message size first,

making
> > it easy to grab the entire message in two reads, and making it easy

to
> > send variable size messages, or change your mind about the message
> > size.
> > I assume that your send routine is sending the data that much_data
> > points to, not the pointer itself.

>
> I think I am so much in this design, that I forgot to
> mention essentials for understanding it for outsiders.
> Sorry about this people. I don't send the XYZ_ind_t
> field, which is only used to indicate which fields of
> the actual data in the rest of the struct needs to be
> send.
>
> I decided to use bit-fields because of their small size
> compared to using a set of booleans (i.e., int's). This
> is because I need to initializa all indicators to 0;
> again a matter of performance. In my real aplication
> there are about 40 optional fields, of which less than
> half are actually being used on average.
>
> In my view, bit-fields are not that performance demanding
> compared to using int's set to 0 or 1. What do you think?
>

It depends upon the processor. Some processors have built-in
bit-handling instructions; some do not. Most mid- to high-range
processors handle ints much more efficiently than they handle individual
bits.

Travis


 
Reply With Quote
 
Felipe Magno de Almeida
Guest
Posts: n/a
 
      07-17-2004
I would use flags either.
--
Felipe Magno de Almeida
Ciencia da Computacao - Unicamp
(E-Mail Removed) - UIN: 146989862
Cause Rock and Roll can never die.
"if you want to learn something really well, teach it to a computer."
What is Communism?
Answer: "Communism is the doctrine of the conditions of the liberation
of the proletariat." (by Karl Marx)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Performance Tutorials Services - Boosting Performance by DisablingUnnecessary Services on Windows XP Home Edition Software Engineer Javascript 0 06-10-2011 02:18 AM
Need good book leads on Programming C++ (Design/Coding) for high performance systems. Kiran C++ 0 07-03-2007 10:28 AM
articles on design increases performance and test first? deanhiller C++ 4 01-10-2006 06:36 PM
Web Form Performance Versus Single File Performance jm ASP .Net 1 12-12-2003 11:14 PM
overload new and delete for performance? (design) Chris E. Yoon C++ 2 07-23-2003 09:36 AM



Advertisments