[sldev] Re: shared objects output during standalone build

[Paul TBBle Hampson]

On Mon, Jul 16, 2007 at 10:57:51AM -0700, Bryan O'Sullivan wrote:
> Paul TBBle Hampson wrote:

> >I'm hoping it wasn't unsharing the shared objects, because I'm pretty
> >sure building those as shared objects cut my build time by about an hour
> >(from three to two), unless someone else can suggest a different 1.17 to
> >1.18 change that would cause that?

> I can't suggest what might have changed this, but I'm skeptical that
> it could have had anything to do with a change of library type.

Well, I'll keep an eye on it. It's possible I forgot to time the gcc-4
build of 1.17, in which case switching to gcc-4 is the only other likely
culprit. I _believe_ that I did check the gcc-4 build time for 1.17 and
it was still three hours.

Anyway, the first-to-mind reason the shared-library build would reduce
build time is because it no longer has to try and hold so much in RAM at
once when linking things. My 512MB laptop goes to swap fairly early on
in the build process (which I blame for most of the three-hour
build-time, a doubly-fast machine with much more RAM does it in like 20
minutes)

> >which I'm guessing is the result of inlining, so unless there's some kind
> >of performance penalty for using shared libraries, I'm all for this
> >state of affairs continuing and even encompassing more. I believe there
> >was a Jira issue around for .soing more of the client...

> I'm afraid that doesn't make any sense.  Using shared objects
> increases viewer startup time and makes packaging more of a pain.

I'm aware (theoretically aware, I've never noticed it myself) it
increases viewer startup time, but I'm not sure why people keep saying
this makes packaging the viewer more of a pain...

Still, making shared libraries load faster is in my experience the job
of prelink, rather than compiling applications statically. Of course,
in this case we don't really get any benefits of building shared
libraries at runtime, since they're not being shared with anything.

In my case, I'm already loading all those system libraries as shared
libraries, rather than using the linden-provided .a files, so I don't
think the performance penalty of loading ll*.so will turn out to be
significant.

I might have a play with compiling more of the objects shared, to see
if that reduces my build turnaround time any further.

Faster build => sooner package releases. ^_^

-- 
-----------------------------------------------------------
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson at Pobox.com

Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
 -- Kristian Wilson, Nintendo, Inc, 1989

License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070717/f34845d8/attachment.pgp