Re: questioning glib r5316 by mclasen
- From: Matthias Clasen <mclasen redhat com>
- To: Behdad Esfahbod <behdad behdad org>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>, Tim Janik <timj imendio com>
- Subject: Re: questioning glib r5316 by mclasen
- Date: Mon, 14 May 2007 08:49:54 -0400
On Mon, 2007-05-14 at 07:10 -0400, Behdad Esfahbod wrote:
> On Mon, 2007-05-14 at 06:49 -0400, Tim Janik wrote:
> > hi Matthias.
> >
> > can you please explain your glib change from 2007-01-26 where you're making
> > function-scoped symbols non-static without any obvious need?
> >
> > i'm sorry to have to bring this up, but your ChangeLog entry is very
> > uninformative on this matter:
> > + * gutils.c: Make some structs which are used only once
> > + non-static.
> > because it uselessly states *what* was done (the diff can tell that
> > already), instead of describing *why* the change was done.
> >
> > thanks for consideration.
>
> Hi Tim,
>
> I'll give a shot at explaining this if you don't mind.
>
> A const struct when defined static will hopefully end up in the
> readonly .data section of the binary and process and everything will be
> perfect. However, if the struct contains pointer arguments (function or
> data) that are initialized to some other symbol, it will need link-time
> relocation and hence cannot live in the readonly data segment anymore,
> and will be moved to regular, writable, .data. The effect is that its
> memory will not be shared across processes.
>
> Now if you make that struct non-static, it will be allocated off the
> stack and initialized at run-time, and disposed when the stack frame
> goes out of scope. No per-process penalty.
>
> In the cases that Matthias committed, the functions in question were
> only run once during a process's lifecycle, so there is not much runtime
> penalty being paid, in return for less link-time overhead and less
> per-process memory use.
>
Yes, thats a pretty good explanation. Thanks, Behdad.
Of course, it doesn't make a huge difference, and thus the change is not
worth fighting over. If you don't like it, just revert it Tim. The only
way to really make a dent in the link-time overhead of gobject-based
libraries would be to get rid of the badly designed enumeration abi that
is forcing thousands of relocations upon us. But we are probably stuck
with that...
Matthias
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]