[Asterisk-Dev] [RFC] strncpy -> ast_copy_string
Kevin P. Fleming
kpfleming at digium.com
Sun May 1 23:05:22 MST 2005
Tilghman Lesher wrote:
> Okay, let me get this straight. You want us to use a function that
> performs slightly slower than the library implementation and offers no
> real advantage (other than some belief that it's "more right"). I'm
> scratching my head. Why are we doing this?
Uhh... why are putting words into my mouth here? I guess I wasn't
explicit enough...
> It might be different if it was actually faster, but you've already
> tested that and found it not to be the case. Let me remind you that
> Asterisk's primary purpose to process calls. Anything that slows
> down that processing and decreases the number of calls we're able
> to process needs a real good reason. Less work is _only_ a valid
> reason if CPU time is decreased. More work or no, the library
> implementation is faster, so that's what we need to keep.
No, I did not "find it to not be the case". I know that the raw "byte
copying" loop in ast_copy_string is slightly slower than strncpy's
byte-copying loop, but the overall performance is a significant
improvement, since strncpy always writes into every byte of the
destination buffer. In fact, just simple logic would dictate that it
would _have_ to be faster, unless the byte copying loop was poorly coded
(which it is not).
In the vast majority of cases in my test Asterisk system, the strncpy
calls are copying strings that consume 25% or less of the target buffer,
and in a great deal of cases (the dialplan specifically) they are
consuming less than 10% of the target buffer. strncpy is writing zeroes
into 75%/90% of the buffer when it's totally unnecessary.
Is that explicit enough?
More information about the asterisk-dev
mailing list