Re: questioning glib r5316 by mclasen



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]