Programming

There's almost nothing there to optimize. At best the difference will be minimal, at worst you'll make it slower. If the compiler can inline htons(), it'll become perhaps one branch-instruction optionally skipping one to three instructions that do the byte swap. That's likely fewer instructions than it takes to call a function, let alone run the code inside it. (and if it's not inlining, that's something you could do...) Function calls can be expensive.

Do you have a _VERY_ good tutorial about profiling with gprof ? I'm actually having
some trouble finding one. I found many, but none that satisfies me.
I'm particularly interested in profiling library code (shared).

Hmm... optimization sometimes lead to very hard to find bugs, at least in my little experience. So I'd rather leave that as my last option.

Thanks again!
S.

---------- Post updated at 09:29 AM ---------- Previous update was at 09:28 AM ----------

Thanks for the explanation!

Regards,
S.

Optimization can cause errors in programs with subtle bugs. Places where accidental writing to stack or incidental return values hadn't mattered before, suddenly may. Proper programming practices will circumvent this, and the benefits of optimization can be very good.

Try a static link - that is one easy way to profile shared routines.
However try these as base assumptions:

most of the problems you have are yours, not library code
algorithms and proper program design give the best return on optimization by far
code tricks result in very minor gains

Do you know about aio (asynchronous I/O)? try reading up on that. It is often used in high demand high volume I/O design (disk). I think it is still not fully supported for sockets in Linux. I don't know for sure.

gprof - this is a good as there is:
GNU gprof

Indeed. That's why I said I'll leave optimization as my last option.

First I'll make it fast and correct (hopefully bug free), then switch to optimization to make
it even faster (even if of a small percentage). At that stage, if a bugs come up, it is easier to find. At least, that's what I've learned.

---------- Post updated at 02:59 AM ---------- Previous update was at 02:51 AM ----------

Hmm... interesting.

In fact, the library is mine! :-D I developed it.

Indeed! I'm not trying to achieve optimization with this kind of tricks.
As I said, I still haven't profiled my code and my post was only about how
to best resolve that particular problem (decoding a payload which byte order
is based on a header flag, which can only be known at runtime).

Yes. I've already read about aio and I did consider it. I might use it for dumping
the data, I receive from the net.


Thanks for the whole reply!