>>5
* sizeof(char) is defined by the standard to be 1.
* strcpy is not the proper function to use in this situation.
* Using strcat requires calloc instead of malloc to be used to ensure NULL-termination.
The corrected code has been attached to this message.
____________________________ Attachments:
>>11
Calloc will null all the memory while you only need one first byte for strcat. The way you use strcat is not optimal either.
I mean, if you care about speed, write it so that it works fast, and if you don't - don't use C.
>>13
After first strcat your string will be "one". When you call strcat the second time, it will have to walk this "one" string to find where it ends and where to append your "two". Third call will have to walk "onetwo" to find its end. You don't need that, you already know when string ends when you append something to it. I'm not going to provide assembly, look at the benchmark one post higher.
>>16
Note that strcat in >>14 walking the length of the string is no different from strlen walking the length of the string in >>11, except that it's more clear to the compiler what you're doing (thus enabling additional optimizations, as shown by the performance increase noted in >>14).
The reason assembly was asked for is because gcc, at least, provides internal implementations for most of the string functions (if -fno-builtins isn't specified, all functions used in this thread are builtins) and does some naughty stuff to decrease runtimes[1]. References:
[1] http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Other-Builtins.html
>>22
Even with your naughty optimizations result are still worse than with the last solution, which is just a slight modification of >>5, who thought that subexpression elimination can be applied here (dumbass). You can't make it work that fast using strcat.
Interestingly enough, with gcc 3.4.6, volatile produces faster code than const (though significantly slower than 4.2):
volatile: >>5 took 1141 ms >>11 took 1309 ms >>14 took 746 ms
const: >>5 took 1135 ms >>11 took 1309 ms >>14 took 766 ms
The signficant difference between the gcc 4.2 and 3.4 output is because the builtins for string manipulations weren't introduced until the 4.x series. This can be demonstrated by disabling builtins --
gcc34 -fno-builtin -O2 test.c >>5 took 1446 ms >>11 took 1434 ms >>14 took 834 ms
gcc -fno-builtin -O2 test.c >>5 took 1471 ms >>11 took 1451 ms >>14 took 896 ms
Anyway, enough of that. Let's all get back to Haskell and pretend this thread was never posted.
Name:
Anonymous2009-01-29 12:02
I wonder why the title says C++ and everyone wants you to mess with character arrays and strcpy like it was C.
String a = "one";
String b = "two";
String c = "three";
StringBuilder s = new StringBuilder();
s.append(a).append(b).append(c);
String d = s.toString();
I benchmarked this and it's 3% faster than >>42. Enjoy your poor performance, C fans.
Name:
Anonymous2009-01-30 0:47
>>48
Which is negated by the -5000% penalty for starting JVM
Name:
Anonymous2009-01-30 0:50
>>48
hahahaha
oh fuck you java fags. I bet you're some college fag who's never done any real programming. oooh, scared of a little assembly are we? oh no not a pointer! whatever shall we do?
goddamn java fags
Name:
Anonymous2009-01-30 0:59
>>50
hahahaha
oh fuck you c fags. I bet you're some college fag who's never done any real programming. oooh, scared of a little garbage collection are we? oh no not a factory! whatever shall we do?
goddamn c fags
also, String d = a + b + c; is actually faster than using StringBuilder in this case because the compiler is smart enough to replace a + b + c with the actual value.