"Frank Behrens" <[EMAIL PROTECTED]> writes: > Joachim B Haga <[EMAIL PROTECTED]> wrote on 9 Dec 2007 1:23: >> It looks like it could be significantly faster in the general case, but >> possibly not if most of the compared times differ in the tv_sec field. >> >> A non-macro variant could be something like >>... > > Good idea. You may help current compilers/processors with an explicit branch > prediction.
Yes. If we know something about the data (I'm not sure I do). > But your code is not bad, because it creates the same output ;-) I think that the __predict_* only decides which branch has to jump, so it is no different than changing the sense of the test. But it does have a documenting effect. But... let's find out a few things. I'll just do a quick profile run... [a bit later] First: In my case, url regexp matching drowns out everything else (90%). timeval_cmp is in the 0.025% range so I wouldn't normally spend much time optimising it ;-) Secondly, 85% of all calls to timeval_cmp differ in tv_sec, so that's correct. Now, 90% of the calls to timeval_cmp come from enqueueTimeEvent. That function walks the event queue to find the right place for a new event. It does it in this order: - try front of queue (33% satisfied in this attempt) - try back of queue (*never* satisfied in this attempt, out of >60000 calls) - walk from last-1 and forwards (67% satisfied, average walk 1.25 places) The surprise is that the back-of-queue never triggers. There is perhaps some long-time event that was enqueued before any others that is hogging this spot? I'm not sure how to use this information, but it may be possible to shave off 20-30% of the calls to timeval_cmp by somehow special-casing this. > #gcc -O2 -march=pentium4 -Wall -fomit-frame-pointer -c -S tst.c polipo uses -Os, results may differ a bit. -j. ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Polipo-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/polipo-users
