On 2 June 2015 at 19:42, Shachar Shemesh via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 01/06/15 18:40, Steven Schveighoffer wrote: >> >> On 5/30/15 2:38 PM, Shachar Shemesh wrote: >> >> So given that a compiler actually *works* (i.e. produces valid >> binaries), is speed of compilation better than speed of execution of the >> resulting binary? > > There is no answer to that question. > > During development stage, there are many steps that have "compile" as a hard > start/end barrier (i.e. - you have to finish a task before compile start, > and cannot continue it until compile ends). During those stages, the > difference between 1 and 10 minute compile is the difference between 1 and > 10 bugs solved in a day. It is a huge difference, and one it is worth > sacrificing any amount of run time efficiency to pay, assuming this is a > tradeoff you can later make. > > Then again, when a release build is being prepared, the difference becomes > moot. Even your "outrageous" figures become acceptable, so long as you can > be sure that no bugs pop up in this build that did not exist in the > non-optimized build. > > Then again, please bear in mind that our product is somewhat atypical. Most > actual products in the market are not CPU bound on algorithmic code. When > that's the case, the optimization stage (beyond the most basic inlining > stuff) will rarely give you 20% overall speed increase. When your code > performs a system call every 40 assembly instructions, there simply isn't > enough room for the optimizer to work its magic. > > One exception to that above rule is where it hurts. Benchmarks, typically, > do rely on algorithmic code to a large extent. > > Shachar
Quality of optimisation is also proportional to battery consumption. Even if the performance increase for a user isn't significant to them in terms of responsiveness, it has an effect on their battery life, which they do appreciate, even if they are unaware of it.