On Fri, 2005-04-22 at 13:59 -0400, Jeffrey Stedfast wrote:
> seems to me like you are trying to micro-optimise and that's a huge
> waste of time.
>
> do you have any profiling data showing that these changes make a
> difference?
For a few minutes of time, this reduces the memory impact of libcamel
(and I've partial patches for libebook too) by moving constant data
to .rodata, which is shared between all processes. Considering e-d-s is
being used by more and more applications, surely this is a good thing.
I doubt it will appear in a profile showing a performance difference (as
the relocations are a one-off cost at startup), but if data is constant,
why not mark it as constant? The C++ people have this right, by making
it good practise to liberally use the const keyword as appropriate.
> On Fri, 2005-04-22 at 17:06 +0100, Ross Burton wrote:
> > Index: camel/camel-object.c
> > ===================================================================
> > RCS file: /cvs/gnome/evolution-data-server/camel/camel-object.c,v
> > retrieving revision 1.52
> > diff -u -r1.52 camel-object.c
> > --- camel/camel-object.c 23 Dec 2004 04:22:43 -0000 1.52
> > +++ camel/camel-object.c 22 Apr 2005 16:04:33 -0000
> > @@ -105,18 +105,18 @@
> > };
> >
> > /* used to tag a bag hookpair */
> > -static const char *bag_name = "object:bag";
> > +static const char bag_name[] = "object:bag\0";
>
> what's with the added \0's?
When doing:
char foo[] = "bar";
foo ended up bytes long and contained 'b' 'a' 'r', which if output using
a stdio will happily write random memory until it comes across a null.
Ross
--
Ross Burton mail: ross burtonini com
jabber: ross burtonini com
www: http://www.burtonini.com./
PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
Attachment:
signature.asc
Description: This is a digitally signed message part