Sorry, I forgot an adjective, condescending. If it makes you feel better to think of me as a student, I'm all for it, send me back and let me do it again.

There are days where I miss Slashdot, this is not one of them. I did read the article (always do) and understood it. You can throw resources at a problem to try and "solve it" by masking the problem(s), but sometimes you actually have to sit down and do the real work to fix it. Sorry if you don't understand that concept.

Thank you for showing me what an arrogant post looks like. ;) Far from a student, and I don't think I qualify as "young" anymore but thank you for trying to make assumptions. Engineers like any other group of people come in all different flavors and there is no magic stereotype that helps you figure out which ones are "better" than others; some are loud, some are quiet, some are great at certain things while others are better at other things - blah, blah, blah...

That would be like me asking you to specifically state exactly why Android needs a 16 GB build environment. What I have stated is not that they are doing it wrong, but the fact that if it truly requires 16 GB to build reasonably then they can probably do a better job of organizing the source and/or build environment. Considering most projects, even larger than Android, build fine with far less resources I don't think that's too much of a stretch.

We probably just disagree about this, but being a common way does not mean its a good way - there's also probably a bit of difference between a project the size of SQLite and Android. I do agree compiler optimizations in general should not cause a problem, but in practice I think more judicial reliance on them decreases the effort in maintaining a solution especially as the size and/or scope of the solution evolves. Even if you were bent on bundling all source files up and sending them to the compiler in one shot, I would think that if you truly need a machine with 16 GB of RAM that would be a good indicator its also a good time to better organize and segregate your code in to more discrete and logical pieces.

Oh? Just what part makes you think I'm a Java programmer?

Nothing arbitrary about it, deliberate would be a better word to use. I'll meet you half way, say instead of a 16 GB or a 640K environment we use an 8 GB build environment?

Forgetting for a second that especially in an embedded style device, I want the results to be very predictable - at what point do you draw the line between compiler optimizations and just plain bad organization or code?

Organize the project better, and you won't have to make that decision or compromise.

If you're advocating packaging everything up and sending it to the compiler in one shot so it can figure things out - no, I would say that is not a good way to optimize a project especially if it has a large code base.