Re: Clone effectiveness

Gary Oberbrunner <[email protected]>
Newsgroups gmane.comp.programming.tools.scons.user
Message-ID <CAFChFyjQus-Ki4WdK6A=JRQOPLFRCu0JG+G=6d1WyvKgE-M_TQ@mail.gmail.com>
Overrides aren't expensive. Go ahead & use them, pass keyword flags to
builders etc.
But let's say you have a sub-SConscript that must use a different compiler
for everything in that subdir. Typical use is to import the main env, clone
it, and modify for all the targets in that sub-SConscript.

On Fri, Sep 14, 2018 at 9:41 AM Hua Yanghao <[email protected]> wrote:

> But seems passing flags also does similar thing with override?
>
> What must be changed in the env that cannot be done with ovrride? as
> majority of the builds are based on variable substitution.
> On Fri, Sep 14, 2018 at 3:12 PM Gary Oberbrunner <[email protected]>
> wrote:
> >
> > Most people use them in a sub-SConscript so they can make changes to the
> env in that script that don't propate up to the calling SConstruct. Not the
> only use case of course, but a popular one.
> >
> > -- Gary
> >
> > On Fri, Sep 14, 2018 at 8:15 AM Hua Yanghao <[email protected]>
> wrote:
> >>
> >> Thanks Gary.
> >>
> >> In this case I think I am mostly using overrides, and only one env per
> >> software image build.
> >>
> >> If we have overrides what are the scenarios that a Clone() of the env
> >> is a must to have?
> >> On Fri, Sep 14, 2018 at 2:03 PM Gary Oberbrunner <[email protected]>
> wrote:
> >> >
> >> > No. It may create an override internally, if you pass some keyword
> args, but that's not a clone. So you can call Object() thousands of times
> for sure.
> >> >
> >> > -- Gary
> >> >
> >> > On Fri, Sep 14, 2018 at 7:56 AM Hua Yanghao <[email protected]>
> wrote:
> >> >>
> >> >> Is every call to "Object()" implicitly creates a clone of
> environment?
> >> >> I seems like so just want to confirm.
> >> >> On Thu, Sep 13, 2018 at 9:20 PM Mats Wichmann <[email protected]>
> wrote:
> >> >> >
> >> >> > On 09/13/2018 12:52 PM, Damien Hocking wrote:
> >> >> > > We do this too.  Most dlls and sos have a cloned environment.
> >> >> >
> >> >> > As I said earlier, we clone lots (>90% of our sconscripts contain a
> >> >> > Clone() call), but the actual build time dwarfs the "process the
> >> >> > SConscripts" phase (*) so I don't worry much about it. We're not
> getting
> >> >> > killed on memory; I can build easily enough in a 2gb
> Vagrant-provisioned
> >> >> > (Linux) image. So while I'd like to *know* the numbers, it's mostly
> >> >> > curiosity.
> >> >> >
> >> >> > Maybe we can resurrect some of the benchmarking/timing code that
> exists
> >> >> > in the codebase now to get more info?
> >> >> >
> >> >> > * - recent build timings:
> >> >> > Total build time: 360.533189 seconds  (using scons -j4)
> >> >> > Total SConscript file execution time: 14.785102 seconds
> >> >> >
> >> >> > 15 seconds is slow, but if I sped up the sconscript time by 50%,
> I'd
> >> >> > still make no more than a 2% impact on the overall time.
> >> >> >
> >> >> > >> On Sep 13, 2018, at 12:27 PM, Pierre-Luc Boily <
> [email protected]> wrote:
> >> >> > >>
> >> >> > >> Hello!
> >> >> > >>
> >> >> > >> Just read on the forum :
> >> >> > >>
> >> >> > >> /Here's the caveat.
> >> >> > >> Don't make a gazillion Clone's they're not lightweight.
> >> >> > >> If you make 100, it won't kill you, if you make 1000's you may
> start seeing
> >> >> > >> memory and speed impacted./
> >> >> > >>
> >> >> > >> Our project branch contains 800 sconscript files.  From those
> 800, 300 are
> >> >> > >> for windows compilation, 500 are for unix compilation.
> >> >> > >>
> >> >> > >> We systematically create a clone of the environment at the
> beginning of
> >> >> > >> *each *sconscript.  So, if I understand well, it might not be
> the best
> >> >> > >> approach.  It would be better to do a Clone only when it is
> needed?
> >> >> > >> Reducing the number of clone could potentially speed up the
> creating of the
> >> >> > >> tree?
> >> >> > >>
> >> >> > >> Thx
> >> >> > >>
> >> >> > >>
> >> >> > >>
> >> >> > >> --
> >> >> > >> Sent from: http://scons.1086193.n5.nabble.com/Users-f16930.html
> >> >> > >> _______________________________________________
> >> >> > >> Scons-users mailing list
> >> >> > >> [email protected]
> >> >> > >> https://pairlist4.pair.net/mailman/listinfo/scons-users
> >> >> > > _______________________________________________
> >> >> > > Scons-users mailing list
> >> >> > > [email protected]
> >> >> > > https://pairlist4.pair.net/mailman/listinfo/scons-users
> >> >> > >
> >> >> >
> >> >> > _______________________________________________
> >> >> > Scons-users mailing list
> >> >> > [email protected]
> >> >> > https://pairlist4.pair.net/mailman/listinfo/scons-users
> >> >> _______________________________________________
> >> >> Scons-users mailing list
> >> >> [email protected]
> >> >> https://pairlist4.pair.net/mailman/listinfo/scons-users
> >> >
> >> >
> >> >
> >> > --
> >> > Gary
> >> > _______________________________________________
> >> > Scons-users mailing list
> >> > [email protected]
> >> > https://pairlist4.pair.net/mailman/listinfo/scons-users
> >> _______________________________________________
> >> Scons-users mailing list
> >> [email protected]
> >> https://pairlist4.pair.net/mailman/listinfo/scons-users
> >
> >
> >
> > --
> > Gary
> > _______________________________________________
> > Scons-users mailing list
> > [email protected]
> > https://pairlist4.pair.net/mailman/listinfo/scons-users
> _______________________________________________
> Scons-users mailing list
> [email protected]
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>


-- 
Gary

_______________________________________________
Scons-users mailing list
[email protected]
https://pairlist4.pair.net/mailman/listinfo/scons-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.