4 ms·
The argument is simple IMO: * release target build times aren't an issue. They can be done overnight and aren't part of the work cycle. * un-optimized build
by streb-lo 6y ago
The argument is simple IMO:
* release target build times aren't an issue. They can be done overnight and aren't part of the work cycle.
* un-optimized build times are part of the work cycle and should be as speedy as possible.
- gpm 6y ago> * release target build times aren't an issue. They can be done overnight and aren't part of the work cycle. Emphasis added. This isn't true for many use cases. There are times when release build + single run is faster than debug build because run time is relatively long (e.g. scientific sims with small code bases + big loops). There are times when debug builds simply aren't sufficient (e.g. when optimizing code).
- streb-lo 6y agoOK that's true but I think my point still stands. Someone who is doing very heavy scientific computation with long-run times will still prefer a release build that is optimizing for run-time speedup over compile-time speedup, within reason of course.
- gpm 6y agoI agree the point still largely stands, that's why I added the emphasis. Maybe I should have made the intent of that clearer.
- kalleboo 6y agoI was going to counter that doesn't WebKit use LLVM to compile hot JavaScript code paths, but it turns out that they have already replaced it with a bespoke optimizer with faster compilation times. https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/ https://webkit.org/blog/5852/introducing-the-b3-jit-compiler...