Re: Reducing unncessary string copying



* Joakim Sindholt <opensource zhasha com> schrieb:

> 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.

hmm, perhaps we'd need to create some real world test scenarios to find out ;-o

> > > 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.

Okay.
BTW: what's g_strdup() actually doing under the hood ? calling libc strdup()
or everything on its own ?

(yes, yes, I should look at the code by myself ... ;-o)

> 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.

Right. That's also what botheres me. So better drop that stupid idea ;-o

I'm now checking if we could make internal (heap allocated)
structures smaller. Allowing those structures also on stack or in
.data could be helpful. Just trying to hack up something for GArray ...


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt metux de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]