Eliminating gettimeofday from construct_reply

[Green, Paul]

Andrew Bartlett [mailto:abartlet at samba.org] wrote:
> Richard Sharpe wrote:
> > 
> > Hi,
> > 
> > I looked at this issue, and it looks possible to accumulate 
> > the timeouts that have occured in receive_message_or_smb and
> > count those up.
> > 
> > Given that the resolution of the dead time parameter is in 
> > minutes, this would seem to not get too far out of whack.
> 
> Sounds like a fair optimization to me - assuming that's what 
> it is for.

Pardon my skepticism, but is there any evidence that calling gettimeofday
from this location in the code is actually contributing in any material way
to the performance of Samba?  Any measurements?  If there isn't, then you
are just optimizing based on by guess and by golly, and could be (almost
certainly will be) introducing a maintenance headache, or an unwitting
platform dependency, by trying to second-guess them.  You could also make
operating Samba from within a debugger (or during profiling) rather touchy,
since your "accumulating" probably won't work in the face of breakpoints.
If this code was mine, I'd insist that you prove to me that this change
would result in at least a 3% or more gain in performance. I seriously doubt
whether you could reach this bar. Why?  Well, in all probability the TCP
stack does multiple time calls all on its own for every packet, and the cost
of sending the data probably far outweighs the cost of reading the clock, so
I think this time call is lost in the noise.

<soapbox>

(1) Operating system engineers know that their time routines are going to
get heavily called and generally try to optimize them.  We certainly try on
our OS.  (2) This routine has fairly high resolution.  If you don't need
this level of resolution, you might use time(), which is probably cheaper,
and certainly no more expensive (and POSIX-compliant, whereas gettimeofday()
is not in POSIX-96).  (3) Optimize based on measurements not reading code.

</soapbox>

Let me just add that I've wasted all too many working days in my career by
trying to optimize code by inspection.  When I actually take the time to run
a benchmark and then optimize the hot spots, I get much better results in
much less (human) time.

Thanks.
PG
--
Paul Green, Senior Technical Consultant, Stratus Computer, Inc.
Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request.