ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> cpp-sig
cpp-sig
Re: [C++-sig] Compile times using Boost::python.
by gideon may other posts by this author
Jun 5 2003 7:19AM messages near this date
Re: [C++-sig] Compile times using Boost::python. | Re: [C++-sig] Compile times using Boost::python.
--On Wednesday, June 04, 2003 4:35 PM -0700 "Ralf W. Grosse-Kunstleve" 
<rwgk@[...].com>  wrote:

>  --- gideon may <gideon@[...].org> wrote:
> > Regarding compilation on Linux in debug mode (gcc 3.2),
> > I have extremely long linking phases, sometimes up to an hour
> > with my application :(. Is there a way to speed this up ?
> > Linking without debug info is much faster.
> 
>  I am always using -O0. If and only if I really need the debug symbols I
>  recompile with -g (with SCons and bjam you can do this without
>  interferring with your -O0 built).

I agree with you, normally I do build release versions (am using bjam),
but in the case that I do need debugging info I normally take lunch :)

> 
> > > 2. Once you have your (run)time-consuming core algorithms implemented
> > > in C++ and wrapped with Boost.Python you can spend most of your time
> > > working with the much more pleasant Python language. I am sometimes
> > > going for weeks without recompiling.
> >
> > Except if you're actively developing the wrapper library and looking
> > for bugs in your code.
> 
>  True, but:
> 
>  - Parallel builts really help.

Agree, if you have a multiprocessor system. And parallel builds don't speed
up the linking phase, which is definitely the bottleneck in the 
edit-compile-test
loop.

>  - Good build systems like SCons and bjam always only recompile what is
>  really needed (i.e. no "make clean" necessary ever).

what is make clean or  bjam clean <wink>  ?

>  - You can maximize the benefits of parallel builts and good build systems
>  by modularizing your code, which is also good for other reasons.

Again, the compilation is fast in comparison with the linking. Unfortunately
I do need to link after I change a single source file. BTW, my library 
consists
of about 100 source files, thus I could say the code is pretty modular.

>  - While developing you can use the fastest platform available. Test on
>  slower platforms later.

With me they are all one and the same  platform :(

Guess I will do some profiling of the gcc linker and file a report, as Dave 
mentioned

ciao
gideon


_______________________________________________
C++-sig mailing list
C++-sig@[...].org
http://mail.python.org/mailman/listinfo/c++-sig
Thread:
Kerim Borchaev
David Abrahams
Ralf W. Grosse-Kunstleve
gideon may
Ralf W. Grosse-Kunstleve
Nicholas K. Sauter
Prabhu Ramachandran
gideon may
Philippe Fremy
Ralf W. Grosse-Kunstleve
gideon may
David Abrahams

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved