>
>
>I bet I can squeeze even more cycles out of this. Have fast_strtoul10
>store its result into a pointer argument, since that's going to be a
>memory write anyway, and return the updated pointer. That'll
>facilitate the pointer staying in a register all the time. Also, you
>make heavy use of flag variables in the fast path -- better to handle
>that with jumps out of the fast path.
>
>Note that the 'register' keyword is ignored by most modern compilers,
>so I feel it's best to leave it out.
>
>
Like I said, it completely fell off the chart when I stopped using
sscanf, and using fast_strtoul10 didn't really save anything over
strtoul as far as I can tell, but someone mentioned strtoul it might not
be very available on every platform, so I rewrote it to be a little quicker.
>Is significant time spent in apr_psprintf or children thereof? Both
>scanf and printf -alikes tend to be slow, and I wouldn't be surprised
>if a similar change helped there too.
>
>
Yes, apr_vformatter is the big guy on the printf side, but it isn't as
much of an issue as sscanf.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 27 01:28:33 2002