Library code can be slower or faster than hand-written code - I'm wondering which is the case for Microsoft's (MingW's) implementation of Shell string functions, in particular StrChrI.
This is an easy one to hand-code & optimize:So I'm wondering which should I use/is faster?Code:char * strchri( const char *s, int c ) { while((*s != '\0') && (*s != (char)toupper(c)) && (*s != (char)tolower(c))) ++s; if(*s == (char)toupper(c) || *s == (char)tolower(c)) return (char *)s; return NULL; }
If you are implying that your code IS optimized, then I would say you are definitely wrong. This is a quick attempt of making it a bit better - there are probably even better variants, but a bit more complex:
[1] Compiler probably doesn't know that toupper is the same very time you call it, so it can't avoid doing that over and over again.Code:char *strchri(const char *s, char c) { char t; c = toupper(c); // Do this ONCE, not every loop. [1] while((t = *s) != 0) // Copy *s [2] { if (toupper(t) == c) { return (char *)s; } s++; } return NULL; }
[2] Only access *s once - we know it's not gong to change [presumably], the compiler MAY expect that no other code [such as toupper] is accessing the memory pointed to by s, but certainly can not be SURE [unless toupper is an inline function, which is uncertain], and many compiler "err on the side of caution".
The second question is: Does it really matter? It is likely that your code is spending more time in other functions which may have more potential for optimization. Have you actually profiled your code to find that strchri is a bottleneck?
If you have some sort of measurement, then try switching from one to the other. You can't really tell which is better without testing it.
By the way, I'm not sure why your code has so many casts.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
I always thought this function should be called strichr(), maybe because of stricmp(). I think I wrote it myself at some point, I know I did a function called stristr() because it didn't came with compilers I've been using.
Anyway, thanks for a link to StrChrI. That should handle well international characters like üéšžîç etc. Functions/makros like toupper() can't really handle utf8 since they expect a single character I suppose.
Seems like a bad case of premature optimisation disease to me.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
not sure myself, I did that quite some time ago and got curious after doing a code-review. It's not bottle-necking or critical - I'm just plain curious as to how optimized a library function like that might be - is it likely that I/you could out-optimize it?
Sure, it's perfectly possible to spend weeks of effort wringing the last few microseconds out of a bit of trivial code.
But a 5-second decision on your part to say choose quick-sort in favour of bubble-sort is something that will save far more time than simple tinkering with the code.
You as designer should be focussing on the big issues of choosing the best algorithms and data structures for the problem at hand. Leave the trivialities to the compiler.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Naturally, but to what degree do they wring it out (i.e. the win32 library implementers)? What I'm asking is just how optimized is win32 library code? we've all heard stories about how some win32 native code is slower than some library X that supposedly emulates it (i.e. WINE)
