What do you do while building?
-
Stuart Dootson wrote:
New hardware's rarely been an option @ work for me
I am lucky, since part of my job role is to recommend new hardware purchases. If they are under $1000 I am usually approved without any problems..
Stuart Dootson wrote:
instead, it's a case of rearranging code and/or distribution of code between files to minimise the impact of changes.
On the latest project I actually did both methods. One such time saver was reducing the number of #include statements in headers. In this I made a lot of use of the PIMPL idiom. http://www.gamedev.net/reference/articles/article1794.asp[^]
John
John M. Drescher wrote:
In this I made a lot of use of the PIMPL idiom
Yep, that one's saved me a LOT of (build-)time over the years!
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
I'm working on a project with a long build duration. How do you normally kill time when you return with your coffee and the build is still busy?
Work on one of my other number-one top priorities :rolleyes:. We have a dedicated build machine, so there's no excuse for not working on something else.
Software Zen:
delete this; -
John M. Drescher wrote:
5 to 15 minutes
New hardware's rarely been an option @ work for me - instead, it's a case of rearranging code and/or distribution of code between files to minimise the impact of changes.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Stuart Dootson wrote:
it's a case of rearranging code and/or distribution of code between files to minimise the impact of changes
That's a horrendous use of your time, IMO.
Software Zen:
delete this; -
I'm working on a project with a long build duration. How do you normally kill time when you return with your coffee and the build is still busy?
I usually get onto the C++ forum of CP.
It is a crappy thing, but it's life -^ Carlo Pallini
-
Stuart Dootson wrote:
it's a case of rearranging code and/or distribution of code between files to minimise the impact of changes
That's a horrendous use of your time, IMO.
Software Zen:
delete this;It's not needed too often in my code, 'cause most of the time I've thought about it before I started. Other people's code, however... And anyway, if I spend the time waiting for builds doing this, then I've kind of not really wasted any time at all.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
It's not needed too often in my code, 'cause most of the time I've thought about it before I started. Other people's code, however... And anyway, if I spend the time waiting for builds doing this, then I've kind of not really wasted any time at all.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
There have been times in the past where I spent a lot of time 'rearranging' code due to factors like compiler limitations and other considerations. The payoff never seemed to match the effort expended.
Software Zen:
delete this; -
I'd rather grab a co-workwer and talk to a coffee.
One place I contracted at, one of the draughtsmen told me that
"Friday afternoons are all meat pies and grope."
I never did find out what he meant but it sounds like your sort of place. :)
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.”
-
Stuart Dootson wrote:
it's a case of rearranging code and/or distribution of code between files to minimise the impact of changes
That's a horrendous use of your time, IMO.
Software Zen:
delete this;For me the reasons for optimizing the hardware, the OS and build process was a result of the following issue: When you change a single line of code in a header file and it takes 30 minutes to produce an new executable its clear that I was not making efficient usage of my time.. Now entire builds happen in less than 10 minutes.
John
-
I'm working on a project with a long build duration. How do you normally kill time when you return with your coffee and the build is still busy?
-
I had that problem once with an MFC project that had a mere 110,000 lines of code and then bought a new PC with 4GB of RAM and the slow builds went away. Albeit, not the best solution but it worked. :)
For my current project, I already had 4GB of RAM but still 30 minute+ builds. The biggest problem is the hard drive would not keep up with my dual core processor so the cores were being utilized less than 25% during parts of the build. After several optimizations (build process, code, hardware, OS) all is well (cores are being utilized 100%) and it usually takes less than 10 minutes for an entire rebuild.
John
-
For my current project, I already had 4GB of RAM but still 30 minute+ builds. The biggest problem is the hard drive would not keep up with my dual core processor so the cores were being utilized less than 25% during parts of the build. After several optimizations (build process, code, hardware, OS) all is well (cores are being utilized 100%) and it usually takes less than 10 minutes for an entire rebuild.
John
-
ouch. Dunno how long you spent tweaking it, but if you were that IO limited a ramdisk to hold temp files probably would've been a really fast payoff.
The European Way of War: Blow your own continent up. The American Way of War: Go over and help them.
Before I got the velociraptor, I thought of that and also a SSD. The biggest problem was what to put on the ram disk. The source would fit easily on a RAM disk but if I would put the build trees for the entire project including its library dependencies (with full source) this takes over 20GB when all 3 builds are generated (debug, release, relwithdebuginfo).
John
-
ouch. Dunno how long you spent tweaking it, but if you were that IO limited a ramdisk to hold temp files probably would've been a really fast payoff.
The European Way of War: Blow your own continent up. The American Way of War: Go over and help them.
dan neely wrote:
Dunno how long you spent tweaking it
A few days for the OS and hard drive change. One problem was I was behind a deadline so I did not have time to optimize. After I delivered a working application (not fully complete) I was able to fix the build issues. One part of this was moving from XP to XP64. I did that when I added the velociraptor. I also doubled the ram to 8GB. The other tweaks to the build process happened before the hard drive / OS update.
John
-
Before I got the velociraptor, I thought of that and also a SSD. The biggest problem was what to put on the ram disk. The source would fit easily on a RAM disk but if I would put the build trees for the entire project including its library dependencies (with full source) this takes over 20GB when all 3 builds are generated (debug, release, relwithdebuginfo).
John
John M. Drescher wrote:
if I would put the build trees for the entire project including its library dependencies (with full source) this takes over 20GB when all 3 builds are generated (debug, release, relwithdebuginfo).
:omg: :omg: How big is your app?! One of mine (~20k LOC in C#) takes <40MB of diskspace for source/debug/release files combined. EXEs+DLLs total under meg for either build. With 12/16gb of ram I'd see if I could configure it to only load the source and build being compiled at the time. With only 8GB I'm not sure it's be feasible unless a lot of the temp files could safely be disposed in mid build (and you could use an event to do so).
The European Way of War: Blow your own continent up. The American Way of War: Go over and help them.
-
John M. Drescher wrote:
if I would put the build trees for the entire project including its library dependencies (with full source) this takes over 20GB when all 3 builds are generated (debug, release, relwithdebuginfo).
:omg: :omg: How big is your app?! One of mine (~20k LOC in C#) takes <40MB of diskspace for source/debug/release files combined. EXEs+DLLs total under meg for either build. With 12/16gb of ram I'd see if I could configure it to only load the source and build being compiled at the time. With only 8GB I'm not sure it's be feasible unless a lot of the temp files could safely be disposed in mid build (and you could use an event to do so).
The European Way of War: Blow your own continent up. The American Way of War: Go over and help them.
dan neely wrote:
How big is your app?! One of mine (~20k LOC in C#) takes <40MB of diskspace for source/debug/release files combined. EXEs+DLLs total under meg for either build.
The main application (with 16 projects) and one external supporting library that I have written are about 75K lines of Qt code together. The rest are 4 libraries that were developed in-house by other members of my team. These are 5 to 20 K lines each. And finally there are 3 large open source libraries (Qt + ITK + VTK) that are under constant development. Each of these 3 libraries are over 500K lines of code. So a rough estimate of the code is 1.8 million lines. I do not rebuild the 3 libraries often so this is not part of the time to build however I may have to build the 5 external libraries daily.
John
-
Thanks! (For some reason the hamsters didn't do their usual magic when I pasted the link)
I have to thank you for Vector-TD. I'm stuck at level 46, that thing can't be beat past that!
If the post was helpful, please vote, eh! Current activities: Book: Devils by Fyodor Dostoyevsky Project: Hospital Automation, final stage Learning: Image analysis, LINQ Now and forever, defiant to the end. What is Multiple Sclerosis[^]?
-
dan neely wrote:
How big is your app?! One of mine (~20k LOC in C#) takes <40MB of diskspace for source/debug/release files combined. EXEs+DLLs total under meg for either build.
The main application (with 16 projects) and one external supporting library that I have written are about 75K lines of Qt code together. The rest are 4 libraries that were developed in-house by other members of my team. These are 5 to 20 K lines each. And finally there are 3 large open source libraries (Qt + ITK + VTK) that are under constant development. Each of these 3 libraries are over 500K lines of code. So a rough estimate of the code is 1.8 million lines. I do not rebuild the 3 libraries often so this is not part of the time to build however I may have to build the 5 external libraries daily.
John
John M. Drescher wrote:
5 external libraries daily.
Is this a typo, or did you neglect to mention something? Your build time/sizes are still huge compared to anything I've done in C#. Do you know if it's just nonlinear scaling or something C++ish to blame. For diskspace it's a ~5x factor (2MB/kloc vs 11MB/kloc); For build times unless there're compiler errors mine builds in 7-40sec for a full rebuild (dunno why the variability; but it seems to go away if I collapse the number of projects down significantly) for a 2-18x difference (30-170kloc/minute vs 9.5-15.5kloc/minute (excluding the 3 big libaries)).
The European Way of War: Blow your own continent up. The American Way of War: Go over and help them.
-
John M. Drescher wrote:
5 external libraries daily.
Is this a typo, or did you neglect to mention something? Your build time/sizes are still huge compared to anything I've done in C#. Do you know if it's just nonlinear scaling or something C++ish to blame. For diskspace it's a ~5x factor (2MB/kloc vs 11MB/kloc); For build times unless there're compiler errors mine builds in 7-40sec for a full rebuild (dunno why the variability; but it seems to go away if I collapse the number of projects down significantly) for a 2-18x difference (30-170kloc/minute vs 9.5-15.5kloc/minute (excluding the 3 big libaries)).
The European Way of War: Blow your own continent up. The American Way of War: Go over and help them.
dan neely wrote:
Is this a typo, or did you neglect to mention something?
More like a bad choice of words. I mean that 5 libraries developed in-house (4 of these from others and my library) are separate workspaces from the workspace that builds the main application.
dan neely wrote:
just nonlinear scaling or something C++ish to blame.
templates are part of the blame for compile times. ITK is a template library. So part of the problem is if you need to #include one of the headers for a template in your header file and that template #include also includes a dozen other template headers many files need to be recompiled for a single change in your header file.
John
-
John M. Drescher wrote:
5 external libraries daily.
Is this a typo, or did you neglect to mention something? Your build time/sizes are still huge compared to anything I've done in C#. Do you know if it's just nonlinear scaling or something C++ish to blame. For diskspace it's a ~5x factor (2MB/kloc vs 11MB/kloc); For build times unless there're compiler errors mine builds in 7-40sec for a full rebuild (dunno why the variability; but it seems to go away if I collapse the number of projects down significantly) for a 2-18x difference (30-170kloc/minute vs 9.5-15.5kloc/minute (excluding the 3 big libaries)).
The European Way of War: Blow your own continent up. The American Way of War: Go over and help them.
dan neely wrote:
For diskspace it's a ~5x factor (2MB/kloc vs 11MB/kloc);
I attribute this to .pdb, .pch, ilk ... files and the number of project files. My .pch files are 15 to 25MB each and the main workspace currently has 21 of them. I know the large open source libraries are much worse.
John
-
I'm working on a project with a long build duration. How do you normally kill time when you return with your coffee and the build is still busy?
concentrate on not hitting my thumb with the hammer :laugh:
Steve _________________ I C(++) therefore I am