This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: on the speed of std::string::find
Am Freitag, den 01.09.2006, 14:02 +0200 schrieb Paolo Carlini:
> Paolo Carlini wrote:
>
> > To be sure: by "my version" you mean, the version you find delivered
> > in libstdc++-v3. Because you are instead calling strstr, when
> > possible. To summarize, that would boil down to providing
> > specializations of find for std::char_traits, char/wchar_t not using
> > generic algorithms but calling strstr and wcsstr directly instead.
>
> Note, I have to warn you that a standard conforming implementation of
> this optimization may not be completely trivial, we have to think a bit
> about it. The issue is that std::basic_string admits '\0' in the middle,
> and you would want to call a mem* functions working on char arrays (like
> in the implementation of char_traits), not str* functions for this kind
> of delegation. But, AFAIK, the C library doesn't deliver such functions...
Right, that is a good point. Embedded \0 is what I overlooked in why it
cannot using strstr. After searching for a while, I have found the GNU
function memmem, and replacing my calls with that leads to factors
between 2 and 10 for memmem beeing still faster than std::string::find.
memmem could also be used for the other variants of find, since it takes
size parameters. Now the question is, if the libstdc++ can rely on
extensions to the libc only beein in the glibc? At least it could try to
detect if the extension is there and then use it. I mean, the libstdc++
is a gnu library... though I don't know much about on what it can rely
and on what not.
greets
Dennis