On Sun, 2012-02-26 at 21:39 +0100, Enrico Weigelt wrote:
> * Joakim Sindholt <opensou...@zhasha.com> schrieb:
>
> Hi,
>
> > I entertained these 2 approaches a bit and the general slowdown (on my
> > machine, an i686) resulted in approximately 10-15% overhead in the
> > following test duplicating strings:
>
> hui!
>
> But, I guess, your system is not under memory presure. (as mine ;-o)
>
Sorry, I should have clarified:
* using a single byte resulted in a 15% CPU time overhead doing this
simple benchmark.
* using a full int it came down to about 10%
But this can probably be ignored in real world applications.
> <snip>
>
> > char *_strdup(const char *str)
> > {
> > int len = strlen(str);
> > char *r = malloc(len+1);
> > memcpy(r, str, len+1);
> > return r;
> > }
>
> Not inlined or macro, so it will always do an full call.
> Perhaps you could try it again w/ inline.
The idea was to take a function (global performance doesn't matter), and
make a version that takes a prefixed string, and one taking a regular
string. Inlining is not going to affect the benchmark and using the real
strdup wouldn't be a fair benchmark.
> > cstr cstrdup(const cstr str)
> > {
> > int len = strlen(str);
> > cstr r = (cstr)malloc(len+1+sizeof(cstrinfo))+sizeof(cstrinfo);
> > memcpy(r, str, len+1);
> > CSTR_INFO(r).flags = 0;
> > return r;
> > }
>
> Maybe optimizable for certain archs.
see above.
> > I have however arrived at the conclusion that you should just leave C
> > strings alone and if it bothers you that much, use a different language
> > in the future. Frankly, regardless of approach, it will create an
> > ABI/API nightmare in existing libraries and applications using g_*
> > functions with strings.
>
> hmm. my intention was to reduce the heap size. optimizing the
> strings was my first idea.
>
> perhaps we should also care of things like int sizes on 64bit, etc.
>
>
> cu
The reason I came to this conclusion was really just because of the ABI
nightmare it would create. You'd have to modify every single application
in existance OR duplicate every API call ever that has a string in it
somewhere, which is also insane.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
