What do you do while building?
-
Thanks! (For some reason the hamsters didn't do their usual magic when I pasted the link)
Jacquers wrote:
Thanks! (For some reason the hamsters didn't do their usual magic when I pasted the link)
yeah! blame it on the hamsters, poor thingie :doh:
Yusuf May I help you?
-
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?
sleep.
This signature was proudly tested on animals.
-
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