Memory footprint and ELF data segment trashing

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Memory footprint and ELF data segment trashing

Mart Raudsepp
Hello.

I took a look on where our symbols end up in ELF binaries, and the look
wasn't all that pretty.
All the wx*NameStr strings end up in .data, instead of .rodata, and same
for all the xpm files.
If they were in .rodata, we would be guaranteed that they are always
shared across applications, but as it is, we are not.

I took a look on the wx*NameStr's. The usual solution is to convert them
from

WXDLLEXPORT_DATA(const wxChar*) str;

to

WXDLLEXPORT_DATA(const wxChar) str[];

Worked good, until I stumbled on some strings that
src/common/datacmn.cpp doesn't declare static once preprocessed through
some headers, such as wxNotebookNameStr, and quite of OS/2 specific ones
(which even OS/2 doesn't use, and hence we simply trash the binary with
the strings, .data at that). I have a list somewhere.
All the strings whose extern declaration src/common/datacmn.cpp pulled
in got exported into .rodata just fine, but once I stumbled upon strings
whose declaration header doesn't get pulled, it died a horrible death.

I'm a bit stumbled here now how to approach this.
Adding extern keyword to the definitions in src/common/datacmn.cpp
resolved the problem for me, but it doesn't feel right, as an extern
keyword in a source file really isn't supposed to do anything, iirc.

Could move all the declarations into a separate header, and include that
when necessary, but something about it doesn't feel right either, as
given preprocessed source, the result would be the same as having it in
the header.

So, exporting with gcc-4.1 gets fixed if the extern keyword is somewhere
told for the strings *while* compiling the src/common/datacmn.cpp
compilation unit. Having it getting included through other compiles
doesn't have an effect, and it's a bit weird, to an extent that I don't
trust to just go and take the separate data header approach without
discussing here.


As for the xpm's going into .data, all our xpm's are non-const.
They should be
static const char *const name_xpm[] = { ... } or some such to go
into .data.rel.ro or .rodata.
Didn't try this yet to see if there are any problems with that.



And for the record, I started checking out the .data trashing because I
looked at what footprint wxGTK leaves to each application. Non-shared
footprint, that is.

Results weren't what I'd call pretty for minimal sample:

Address   Kbytes     RSS    Anon  Locked Mode   Mapping
<snip>
b7b7d000    1048       -       -       - r-x--  libwx_baseu-2.7.so.0.0.0
b7c83000      40       -       -       - rw---  libwx_baseu-2.7.so.0.0.0
b7c8d000      48       -       -       - rw---    [ anon ]
b7c99000    2540       -       -       - r-x--  libwx_gtk2u_core-2.7.so.0.0.0
b7f14000     168       -       -       - rw---  libwx_gtk2u_core-2.7.so.0.0.0
b7f3e000      24       -       -       - rw---    [ anon ]

So, 40KB from wxBase and 168KB from wxCore alone. I'd expect below 16KB
and 48KB. wxAdv doesn't seem to add much at least.
This is then wasted memory beyond the first wx application. Memory used
by the library itself, that can't be shared between multiple
applications linking to wx.

For comparison libgtk has a 32KB footprint (plus perhaps some hidden
stuff like gdkrgb worth 96 pixels * depth), and the rest of the gtk+
stack not more than 12KB (three pages).
It is told that GTK+'s memory footprint per application is too large.
Gives a vague idea where we stand.
I hope to work more on getting to the bottom of this over time. But
noting here to raise awareness and perhaps prod someone to look into
it ;)

If I made any errors in my conclusions above, please let me know.

--
With regards,
Mart Raudsepp

Project manager of wxMUD
E-mail: [hidden email]
http://wxmud.sourceforge.net/


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Memory footprint and ELF data segment trashing

Vadim Zeitlin-3
On Sun, 15 Jan 2006 08:05:17 +0200 Mart Raudsepp <[hidden email]> wrote:

MR> All the wx*NameStr strings end up in .data, instead of .rodata, and same
MR> for all the xpm files.

 Independently of this I really wonder why do we need to put all these
symbols in a single file instead of the .cpp file of the appropriate
control. This way we create absolutely unneeded link dependencies for no
good reason.

MR> I took a look on the wx*NameStr's. The usual solution is to convert them
MR> from
MR>
MR> WXDLLEXPORT_DATA(const wxChar*) str;
MR>
MR> to
MR>
MR> WXDLLEXPORT_DATA(const wxChar) str[];
MR>
MR> Worked good, until I stumbled on some strings that
MR> src/common/datacmn.cpp doesn't declare static once preprocessed through
MR> some headers,

 Sorry, I couldn't understand what does this mean?

MR> Adding extern keyword to the definitions in src/common/datacmn.cpp
MR> resolved the problem for me, but it doesn't feel right, as an extern
MR> keyword in a source file really isn't supposed to do anything, iirc.

 It does do something: namely gives symbol external linkage. It absolutely
doesn't matter whether you do it in a header or a source file.

MR> Could move all the declarations into a separate header

 This would be even worse as we'd have not only linking but compilation
dependencies too. I'd just declare each wxFooNameStr in wx/foo.h and
implement it in common/foocmn.cpp.

MR> As for the xpm's going into .data, all our xpm's are non-const.
MR> They should be
MR> static const char *const name_xpm[] = { ... } or some such to go
MR> into .data.rel.ro or .rodata.
MR> Didn't try this yet to see if there are any problems with that.

 AFAIR the reason for not using const here is that some (all?) XPM editing
tools get confused by it.

 Regards,
VZ


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Memory footprint and ELF data segment trashing

Mart Raudsepp
On Sun, 2006-01-15 at 13:34 +0100, Vadim Zeitlin wrote:
> On Sun, 15 Jan 2006 08:05:17 +0200 Mart Raudsepp <[hidden email]> wrote:
>
> MR> All the wx*NameStr strings end up in .data, instead of .rodata, and same
> MR> for all the xpm files.
>
>  Independently of this I really wonder why do we need to put all these
> symbols in a single file instead of the .cpp file of the appropriate
> control. This way we create absolutely unneeded link dependencies for no
> good reason.

Another way we create a complete maintenance nightmare, imho. All are
linked into core right now.

> MR> I took a look on the wx*NameStr's. The usual solution is to convert them
> MR> from
> MR>
> MR> WXDLLEXPORT_DATA(const wxChar*) str;
> MR>
> MR> to
> MR>
> MR> WXDLLEXPORT_DATA(const wxChar) str[];
> MR>
> MR> Worked good, until I stumbled on some strings that
> MR> src/common/datacmn.cpp doesn't declare static once preprocessed through
> MR> some headers,
>
>  Sorry, I couldn't understand what does this mean?

Worked good, until I stumbled on some strings that
src/common/datacmn.cpp doesn't declare _extern_ (typo) through some
headers once preprocessed.
datacmn.cpp includes quite some headers, I suppose it was because I used
precompiled headers. All these headers that get included declare quite
some of the strings extern, but not all. All which are declared extern
get exported into binary once moved to .rodata, all that aren't declared
extern somewhere are left out of the binary.
I compared the objdump's of before and after making strings wxChar str[]
instead of wxChar* and searched for these from gcc -E datacmn.cpp ..
output.

> MR> Adding extern keyword to the definitions in src/common/datacmn.cpp
> MR> resolved the problem for me, but it doesn't feel right, as an extern
> MR> keyword in a source file really isn't supposed to do anything, iirc.
>
>  It does do something: namely gives symbol external linkage. It absolutely
> doesn't matter whether you do it in a header or a source file.
>
> MR> Could move all the declarations into a separate header
>
>  This would be even worse as we'd have not only linking but compilation
> dependencies too. I'd just declare each wxFooNameStr in wx/foo.h and
> implement it in common/foocmn.cpp.

As an interim solution adding extern keyword to all the strings in
datacmn.cpp should work too (for all compilers to still export them)?
I'm a bit time constrained right now to do the moving.
I'm not that thrilled about not having the strings all in one place
either.

> MR> As for the xpm's going into .data, all our xpm's are non-const.
> MR> They should be
> MR> static const char *const name_xpm[] = { ... } or some such to go
> MR> into .data.rel.ro or .rodata.
> MR> Didn't try this yet to see if there are any problems with that.
>
>  AFAIR the reason for not using const here is that some (all?) XPM editing
> tools get confused by it.

Doesn't sound like a reason to not have the xpm's in read-only data
segment, that is guaranteed to be shared across processes linking to the
library.
Tried GIMP. It doesn't get confused. But, alas, once saved (at least as
another name), it doesn't write "const" out, so need to hand-edit after
it.
Found http://bugzilla.gnome.org/show_bug.cgi?id=7575 for reference too.

--
With regards,
Mart Raudsepp

Project manager of wxMUD
E-mail: [hidden email]
http://wxmud.sourceforge.net/


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re[2]: Memory footprint and ELF data segment trashing

Vadim Zeitlin-3
On Sun, 15 Jan 2006 21:05:28 +0200 Mart Raudsepp <[hidden email]> wrote:

MR> On Sun, 2006-01-15 at 13:34 +0100, Vadim Zeitlin wrote:
MR> > On Sun, 15 Jan 2006 08:05:17 +0200 Mart Raudsepp <[hidden email]> wrote:
MR> >
MR> > MR> All the wx*NameStr strings end up in .data, instead of .rodata, and same
MR> > MR> for all the xpm files.
MR> >
MR> >  Independently of this I really wonder why do we need to put all these
MR> > symbols in a single file instead of the .cpp file of the appropriate
MR> > control. This way we create absolutely unneeded link dependencies for no
MR> > good reason.
MR>
MR> Another way we create a complete maintenance nightmare, imho.

 How so?

MR> All are linked into core right now.

 Another thing which doesn't make sense. Why should the names of adv
controls be in core?

MR> Found http://bugzilla.gnome.org/show_bug.cgi?id=7575 for reference too.

 This URL gives "Invalid Bug ID.Bug #7575 does not exist." to me,

 Regards,
VZ


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: Memory footprint and ELF data segment trashing

Mart Raudsepp
On Sun, 2006-01-15 at 20:38 +0100, Vadim Zeitlin wrote:

> On Sun, 15 Jan 2006 21:05:28 +0200 Mart Raudsepp <[hidden email]> wrote:
>
> MR> On Sun, 2006-01-15 at 13:34 +0100, Vadim Zeitlin wrote:
> MR> > On Sun, 15 Jan 2006 08:05:17 +0200 Mart Raudsepp <[hidden email]> wrote:
> MR> >
> MR> > MR> All the wx*NameStr strings end up in .data, instead of .rodata, and same
> MR> > MR> for all the xpm files.
> MR> >
> MR> >  Independently of this I really wonder why do we need to put all these
> MR> > symbols in a single file instead of the .cpp file of the appropriate
> MR> > control. This way we create absolutely unneeded link dependencies for no
> MR> > good reason.
> MR>
> MR> Another way we create a complete maintenance nightmare, imho.
>
>  How so?
>
> MR> All are linked into core right now.
>
>  Another thing which doesn't make sense. Why should the names of adv
> controls be in core?

These should be moved elsewhere into an adv file, yes.

> MR> Found http://bugzilla.gnome.org/show_bug.cgi?id=7575 for reference too.
>
>  This URL gives "Invalid Bug ID.Bug #7575 does not exist." to me,

Whoops.
http://bugzilla.gnome.org/show_bug.cgi?id=75754

http://cvs.gnome.org/viewcvs/gtk%2B/gtk/tree_minus.xpm?rev=1.2.6.1&view=markup

Made the xpm's const too. Result:
../src/common/../../art/gtk/error.xpm:2: error: duplicate 'const'
with static const char *const error_xpm[] = { ... };
which is a bit weird without investigation, as it works for e.g GTK+.

Converting to static char *const error_xpm[] = { ... }; got rid of the
error (and perhaps also from moving to .rodata), but hit wxBitmap ctor
differences:


../src/common/artstd.cpp:158: error: call of overloaded 'wxBitmap(const
char* const [53])' is ambiguous
../include/wx/gtk/bitmap.h:78: note: candidates are:
wxBitmap::wxBitmap(const wxImage&, int) <near match>
../include/wx/gtk/bitmap.h:77: note:
wxBitmap::wxBitmap(const wxString&, wxBitmapType) <near match>
../include/wx/gtk/bitmap.h:76: note:
wxBitmap::wxBitmap(const wxBitmap&) <near match>
../include/wx/gtk/bitmap.h:75: note:
wxBitmap::wxBitmap(char**) <near match>
../include/wx/gtk/bitmap.h:74: note:
wxBitmap::wxBitmap(const char**) <near match>

Could make it compile with adding a couple const's here and there, but
not really confident in the area of const correctness myself :(

Maybe should provide all versions of ctor's regardings consts, and send
it all to a fully const CreateFromXpm?

--
With regards,
Mart Raudsepp

Project manager of wxMUD
E-mail: [hidden email]
http://wxmud.sourceforge.net/


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

ABX
Reply | Threaded
Open this post in threaded view
|

Re: Memory footprint and ELF data segment trashing

ABX
In reply to this post by Vadim Zeitlin-3
Vadim Zeitlin <vadim@...> writes:
> Independently of this I really wonder why do we need to put all these
> symbols in a single file instead of the .cpp file of the appropriate
> control.

I think it predates multilib configutation. Looking back to year 1998 in
src/msw/data.cpp, it was always this way. On the other hand doing
http://thread.gmane.org/gmane.comp.lib.wxwidgets.devel/32127 you meant that it
is handy to have this elements centralised. I would expect that moving them into
.cpp file of the appropriate control could lead to having it duplicated across
ports again. It surely is possible to create common/*.cpp for every wx*CtrlBase
controls but having datacmn.cpp looks a lot easier once it is carefully
considered to have it all in relation to core. So apart 'extern' changes Mart
mentioned, we only need split into:
src/common/basecmn.cpp
src/common/corecmn.cpp
src/common/advcmn.cpp
etc.

ABX


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Memory footprint and ELF data segment trashing

Vadim Zeitlin-3
On Sun, 15 Jan 2006 21:27:23 +0000 (UTC) ABX <[hidden email]> wrote:

A> Vadim Zeitlin <vadim@...> writes:
A> > Independently of this I really wonder why do we need to put all these
A> > symbols in a single file instead of the .cpp file of the appropriate
A> > control.
A>
A> I think it predates multilib configutation.

 Yes, of course. But it's not a reason to not change it.

A> Looking back to year 1998 in
A> src/msw/data.cpp, it was always this way. On the other hand doing
A> http://thread.gmane.org/gmane.comp.lib.wxwidgets.devel/32127 you meant that it
A> is handy to have this elements centralised.

 No, sorry, this wasn't at all the same thing. I argued against duplicating
them, because there were actually both datacmn.cpp *and* per-port data.cpp.
This was obviously even worse than the current situation.

A> I would expect that moving them into cpp file of the appropriate control
A> could lead to having it duplicated across ports again.

 For many classes we already have foocmn.cpp where the names could be
declared without duplicating them.

A> It surely is possible to create common/*.cpp for every wx*CtrlBase
A> controls but having datacmn.cpp looks a lot easier

 At the very least it pulls a lot of potentially unnecessary stuff in any
wx program.

 Regards,
VZ


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

ABX
Reply | Threaded
Open this post in threaded view
|

Re: Memory footprint and ELF data segment trashing

ABX
Vadim Zeitlin <vadim@...> writes:
> At the very least it pulls a lot of potentially unnecessary stuff in any
> wx program.

I can easily miss some technical issue here but I feel above relates only to
static linking, and this seems already the case regardless .cpp file used if
correct wxUSE_* is not applied or nor disabled in setup? Sorry in advance if my
thinking about linking is MSW-only.

ABX


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Memory footprint and ELF data segment trashing

Vadim Zeitlin-3
On Sun, 15 Jan 2006 21:43:48 +0000 (UTC) ABX <[hidden email]> wrote:

A> Vadim Zeitlin <vadim@...> writes:
A> > At the very least it pulls a lot of potentially unnecessary stuff in any
A> > wx program.
A>
A> I can easily miss some technical issue here but I feel above relates only to
A> static linking,
 
 Yes.

A> and this seems already the case regardless .cpp file used if correct
A> wxUSE_* is not applied or nor disabled in setup?

 Of course you can exclude all unused stuff carefully by setting wxUSE_XXX
to 0 but, let's be honest, nobody does it.

 Regards,
VZ


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

ABX
Reply | Threaded
Open this post in threaded view
|

Re: Memory footprint and ELF data segment trashing

ABX
Vadim Zeitlin <vadim@...> writes:

> A> Vadim Zeitlin <vadim <at> ...> writes:
> A> > At the very least it pulls a lot of potentially unnecessary stuff in any
> A> > wx program.
> A>
> A> I can easily miss some technical issue here but I feel above relates only to
> A> static linking,
>
>  Yes.
>
> A> and this seems already the case regardless .cpp file used if correct
> A> wxUSE_* is not applied or nor disabled in setup?
>
>  Of course you can exclude all unused stuff carefully by setting wxUSE_XXX
> to 0 but, let's be honest, nobody does it.

So to be honest further, does it mean that moving them from datacmn.cpp to
control .cpp file will not allow magically to avoid pulling a lot of potentially
unnecessary stuff in any wx program as long as datacmn.cpp and somecontrol.cpp
both are in core? I supposed that famouse (at least with wxMSW) "large
wx-exacutables size" issue comes from the fact that all the controls are always
linked in due to some casts and testing in code.

I raised this issue because with wxSymbian I expect to use native literals for
these labels and these native literals would be easier to be incorporated in
single datacmn.cpp file single large #ifdef __SYMBIAN__ ... #else ... #endif
rather making all controlbase.cpp dirty of #ifdefs. Also I progressed wxPalm for
older Palms and i feel I will have play with static literals too. So all in all
I would prefer to clearly understand all benefits from datacmn.cpp depreciacion.

ABX


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Memory footprint and ELF data segment trashing

Vadim Zeitlin-3
On Sun, 15 Jan 2006 22:04:48 +0000 (UTC) ABX <[hidden email]> wrote:

A> So to be honest further, does it mean that moving them from datacmn.cpp to
A> control .cpp file will not allow magically to avoid pulling a lot of potentially
A> unnecessary stuff in any wx program as long as datacmn.cpp and somecontrol.cpp
A> both are in core?

 Sorry, I don't understand this. All I say is that currently you always get
the entire contents of datacmn.cpp (which is certainly not huge but still,
why always link it in). If the control names were in their own files, you
wouldn't. Is there really anything to discuss here?

A> I supposed that famouse (at least with wxMSW) "large wx-exacutables
A> size" issue comes from the fact that all the controls are always linked
A> in due to some casts and testing in code.

 This is surely due to (much) more than this datacmn.cpp issue. And,
indeed, the above reason is one of the explanations. So big exe size is not
going to be fixed by this change but it would still help a tiny bit.

A> I raised this issue because with wxSymbian I expect to use native
A> literals for these labels and these native literals would be easier to
A> be incorporated in single datacmn.cpp file single large #ifdef
A> __SYMBIAN__ ... #else ... #endif rather making all controlbase.cpp dirty
A> of #ifdefs.

 You should be able to define some wxDEFINE_STRING macro, shouldn't you?

 Regards,
VZ


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Memory footprint and ELF data segment trashing

Mart Raudsepp
On Mon, 2006-01-16 at 03:40 +0100, Vadim Zeitlin wrote:

> On Sun, 15 Jan 2006 22:04:48 +0000 (UTC) ABX <[hidden email]> wrote:
>
> A> So to be honest further, does it mean that moving them from datacmn.cpp to
> A> control .cpp file will not allow magically to avoid pulling a lot of potentially
> A> unnecessary stuff in any wx program as long as datacmn.cpp and somecontrol.cpp
> A> both are in core?
>
>  Sorry, I don't understand this. All I say is that currently you always get
> the entire contents of datacmn.cpp (which is certainly not huge but still,
> why always link it in).

You not only get it always in, you could get it into per application
memory footprint.

> If the control names were in their own files, you
> wouldn't. Is there really anything to discuss here?

I will commit the .data -> .rodata moves with the extern keyword then
for now (wxChar* str to extern wxChar str[]) out of the way, and after
that we can move parts to other files, as soon someone figures out which
strings are used in which library.

--
With regards,
Mart Raudsepp

Project manager of wxMUD
E-mail: [hidden email]
http://wxmud.sourceforge.net/


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

ABX
Reply | Threaded
Open this post in threaded view
|

Re: Re: Memory footprint and ELF data segment trashing

ABX
In reply to this post by Vadim Zeitlin-3
Vadim Zeitlin <[hidden email]>:
> On Sun, 15 Jan 2006 22:04:48 +0000 (UTC) ABX <[hidden email]> wrote:
> A> So to be honest further, does it mean that moving them from datacmn.cpp to
> A> control .cpp file will not allow magically to avoid pulling a lot of potentially
> A> unnecessary stuff in any wx program as long as datacmn.cpp and somecontrol.cpp
> A> both are in core?
>
> Sorry, I don't understand this.

I meant that I do not understand how buttoncmn.cpp is better than datacmn.cpp
if both would be in core lib and both could have the same wxUSE_BUTTON around
wxButtonNameStr. Are we talking only about missing wxUSE_* flags here or
something else? If noone is editing setup.h, as you stated, than how using
different .cpp file could remove this symbol during linking?

ABX


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Memory footprint and ELF data segment trashing

Stefan.Neis@t-online.de
             Hi,

> I meant that I do not understand how buttoncmn.cpp is better than
datacmn.cpp
> if both would be in core lib and both could have the same wxUSE_BUTTON

> around wxButtonNameStr.

Well, button might be a particularly bad example, but take something
that's
not used quite as frequently, say "wxGetPasswordFromUserPromptStr".
Currently, that string is linked into _every_ wx application, no matte
if it
uses that dialog or not. If it's moved to utilscmn.cpp, it's going to be
linked
only into applications using anything from that file and if you move the
constant and the corresponding dialog into a separate file, they will be
only linked into applications using that dialog. Keep in mind that the
static linker goes through the libraries object file by object file,
deciding
which ones need to be linked in and which don't, not the even more
stupid library by library. And some (very few) linkers are clever enough
to
do it even symbol by symbol.

          Regards,
                     Stefan



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re[2]: Re: Memory footprint and ELF data segment trashing

Vadim Zeitlin-3
In reply to this post by ABX
On Mon, 16 Jan 2006 11:12:31 +0100 ABX <[hidden email]> wrote:

A> I meant that I do not understand how buttoncmn.cpp is better than datacmn.cpp

 It would be better for an application not using buttons (but using other
controls). Of course, this particular case is quite unlikely, but an
application using buttons, text controls and listboxes but not, say, tree
control and 50 other controls (and hence 50 other name strings) is less so.
As I said, this is a relatively minor gain but it's still a gain and one
which seems to be "free" in the sense that I don't see what do we lose by
doing it.

 Regards,
VZ


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: Re: Memory footprint and ELF data segment trashing

Mart Raudsepp
On Mon, 2006-01-16 at 18:50 +0100, Vadim Zeitlin wrote:

> On Mon, 16 Jan 2006 11:12:31 +0100 ABX <[hidden email]> wrote:
>
> A> I meant that I do not understand how buttoncmn.cpp is better than datacmn.cpp
>
>  It would be better for an application not using buttons (but using other
> controls). Of course, this particular case is quite unlikely, but an
> application using buttons, text controls and listboxes but not, say, tree
> control and 50 other controls (and hence 50 other name strings) is less so.
> As I said, this is a relatively minor gain but it's still a gain and one
> which seems to be "free" in the sense that I don't see what do we lose by
> doing it.

I can see how this can be useful when e.g adv strings aren't put into
core library, but I don't think I understand how having them
side-by-side with the appropriate control can be a win beyond that.

Does some compiler remember in what file something was, and go from
there with something?

I would propose having something like datacore.cpp, dataadv.cpp, etc and
spread the strings out there, as appropriate. Of course making
datacore.cpp part of wxCore and dataadv.cpp part of wxAdv.

--
With regards,
Mart Raudsepp

Project manager of wxMUD
E-mail: [hidden email]
http://wxmud.sourceforge.net/


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: Re: Memory footprint and ELF data segment trashing

Mart Raudsepp
On Mon, 2006-01-16 at 20:06 +0200, Mart Raudsepp wrote:

> On Mon, 2006-01-16 at 18:50 +0100, Vadim Zeitlin wrote:
> > On Mon, 16 Jan 2006 11:12:31 +0100 ABX <[hidden email]> wrote:
> >
> > A> I meant that I do not understand how buttoncmn.cpp is better than datacmn.cpp
> >
> >  It would be better for an application not using buttons (but using other
> > controls). Of course, this particular case is quite unlikely, but an
> > application using buttons, text controls and listboxes but not, say, tree
> > control and 50 other controls (and hence 50 other name strings) is less so.
> > As I said, this is a relatively minor gain but it's still a gain and one
> > which seems to be "free" in the sense that I don't see what do we lose by
> > doing it.
>
> I can see how this can be useful when e.g adv strings aren't put into
> core library, but I don't think I understand how having them
> side-by-side with the appropriate control can be a win beyond that.
>
> Does some compiler remember in what file something was, and go from
> there with something?

Hmm, seems I'm simply a bit disagreeing with my mail client on what mail
I have read and what not, or I'm just blind. Sorry. Stefan seems to have
explained this.
Personally I think that trying to maintain perfect support for wxUSE_*
setting is a battle lost in the beginning.

> I would propose having something like datacore.cpp, dataadv.cpp, etc and
> spread the strings out there, as appropriate. Of course making
> datacore.cpp part of wxCore and dataadv.cpp part of wxAdv.

Then might think about putthing them into buttoncmn.cpp and co as
appropriate too, given that it's wrapped with the appropriate wxUSE_*.
Though I fear it will be bad to maintain. Will wait what we end up
deciding.

--
With regards,
Mart Raudsepp

Project manager of wxMUD
E-mail: [hidden email]
http://wxmud.sourceforge.net/


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

ABX
Reply | Threaded
Open this post in threaded view
|

Re: Memory footprint and ELF data segment trashing

ABX
In reply to this post by Mart Raudsepp
Mart Raudsepp <[hidden email]>:

> I took a look on the wx*NameStr's. The usual solution is to convert them
> from
>
> WXDLLEXPORT_DATA(const wxChar*) str;
>
> to
>
> WXDLLEXPORT_DATA(const wxChar) str[];
>
> Worked good, until I stumbled on some strings that
> src/common/datacmn.cpp doesn't declare static once preprocessed through
> some headers, such as wxNotebookNameStr, and quite of OS/2 specific ones
> (which even OS/2 doesn't use, and hence we simply trash the binary with
> the strings, .data at that). I have a list somewhere.
> All the strings whose extern declaration src/common/datacmn.cpp pulled
> in got exported into .rodata just fine, but once I stumbled upon strings
> whose declaration header doesn't get pulled, it died a horrible death.

I slowly recheck all MSW builds with your changes and got DMC builds broken.
All strings of datacmn.cpp are undefined references now. Removal of all your
'extern' from datacmn.cpp removes this problem. BTW: label wxUserResourceStr
seem to be good candidate to your changes too but somehow is not touched.

ABX


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Memory footprint and ELF data segment trashing

Mart Raudsepp
On Tue, 2006-01-17 at 12:54 +0100, ABX wrote:
> I slowly recheck all MSW builds with your changes and got DMC builds broken.
> All strings of datacmn.cpp are undefined references now. Removal of all your
> 'extern' from datacmn.cpp removes this problem.

Interesting. Some were declared extern anyway before from headers
included by datacmn.cpp, just not like 12 strings, wxNotebookNameStr and
11 others.
Any ideas on how to fix this? Some WXEXPORT alike macro perhaps?
The strings need to end up as symbols in the library. Without the extern
they don't with gcc.

> BTW: label wxUserResourceStr
> seem to be good candidate to your changes too but somehow is not touched.

Yeah, some were untouched for now, and some that were untouched should
go the way of the dodo. wxUserResourceStr should probably be changed
too, not sure why I skipped that. I saw all of them with
objdump -x libwx_gtk2u_core-2.7.so |grep -e '[.]data' |grep -v
'[.]data[.]rel[.]ro'

--
With regards,
Mart Raudsepp

Project manager of wxMUD
E-mail: [hidden email]
http://wxmud.sourceforge.net/


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

ABX
Reply | Threaded
Open this post in threaded view
|

Re: Memory footprint and ELF data segment trashing

ABX
Mart Raudsepp <[hidden email]>:
> On Tue, 2006-01-17 at 12:54 +0100, ABX wrote:
> > I slowly recheck all MSW builds with your changes and got DMC builds broken.
> > All strings of datacmn.cpp are undefined references now. Removal of all your
> > 'extern' from datacmn.cpp removes this problem.
>
> Interesting. Some were declared extern anyway before from headers
> included by datacmn.cpp, just not like 12 strings, wxNotebookNameStr and
> 11 others.

I guess wxListCtrlNameStr is between them? wxListCtrlNameStr and
wxNotebookNameStr are still unresolved as I see.

> Any ideas on how to fix this? Some WXEXPORT alike macro perhaps?

I think so. Or perhaps we could make it similar to DECLARE/DEFINE pattern
used for classes:

  #define WXDECLARE_NAME(name) extern WXDLLEXPORT_DATA(const wxChar) name[]
  #ifdef __DMC__
      #define WXDEFINE_NAME(name,value) WXDLLEXPORT_DATA(const wxChar) name[] = value
  #else
      #define WXDEFINE_NAME(name,value) WXDECLARE_NAME(name) = value
  #endif

but not tested. Not sure if _T() should be outside or inside WXDEFINE_NAME.

> > BTW: label wxUserResourceStr
> > seem to be good candidate to your changes too but somehow is not touched.
>
> Yeah, some were untouched for now, and some that were untouched should
> go the way of the dodo. wxUserResourceStr should probably be changed
> too, not sure why I skipped that. I saw all of them with
> objdump -x libwx_gtk2u_core-2.7.so |grep -e '[.]data' |grep -v
> '[.]data[.]rel[.]ro'

I guess 'gtk' above says it all. IIRC wxUserResourceStr was within
#ifdef Windows || OS2

ABX


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12