Andrew Bartlett [mailto:[EMAIL PROTECTED]] 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.
