This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]