[sldev] Re: shared objects output during standalone build

[Dana Fagerstrom]

Paul,

One thing many people don't realize is that scons supports the -j option 
  just like make/dmake.  That option instructs scons to perform multiple 
compiles.  On a "fast" system a "-j 2" or even "-j 4"  will greatly 
decrease build time.

On my Ultra 40 (2 AMD dual core CPUs) I run with "-j 8" and a complete 
build plus packaging is completed in less than an hour.

HTH,
D (aka Whoops Babii)
http://blogs.sun.com/daner/

Paul TBBle Hampson wrote:
> 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. ^_^
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html