# Rethinking optimization, lower ok for all Julia code (for e.g. faster startup) as a default?

**URL:** <https://discourse.julialang.org/t/rethinking-optimization-lower-ok-for-all-julia-code-for-e-g-faster-startup-as-a-default/39843>\
**Category:** General Usage\
**Created:** [May 20, 2020, 4:22pm UTC](https://discourse.julialang.org/t/rethinking-optimization-lower-ok-for-all-julia-code-for-e-g-faster-startup-as-a-default/39843 "2020-05-20T16:22:39Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [May 20, 2020, 9:29pm UTC](https://discourse.julialang.org/t/rethinking-optimization-lower-ok-for-all-julia-code-for-e-g-faster-startup-as-a-default/39843/3 "2020-05-20T21:29:24Z")

</div>

> [@kristoffer.carlsson](#):
>
> How are you benchmarking to make sure that your PRs does not introduce runtime regressions?

I’m not (at least yet; for Revise, I’m just using it with the change and haven’t seen a difference). It’s up to the maintainer, and I mention a possible slowdown (I guess why all but one PRs are open, and that one closed unmerged).

It’s not like I suggest[ed] this for packages I know it would hurt. I’ve only done it, until this post, if I think it will likely help (and I see faster startup, as I always do, find it likely to be for all or most packages).

Jeff did this first for Plots.jl, then that I know has of been done for PyCall.jl, so I suggested for similar packages.

I was most cautious at JavaCall.jl with “MIGHT be a slowdown” and got a “thank you for suggesting this. I’m looking into it.” I let the maintainers decide. Some are a no-brainers like RDatasets.jl, while PR still open with “this makes sense to me.”

> <https://github.com/JuliaInterop/RCall.jl/pull/383>

While in the post here “I suggest changing the default”, I do not mean right away. Julia 1.5 is around the corner, and it’s seems like a good release I wouldn’t want to spoil.

It would be good for people to try this out `-O1` first to be conservative, so that we can see the effect. I’m just one person and can’t test all packages. I do expect a slowdown for some code, but less often than people may think, and then they can add `-O2` back (selectively), or even -O3, or `@avx` etc.

There’s even a “A superoptimizer for LLVM” we could try: [GitHub - google/souper: A superoptimizer for LLVM IR](https://github.com/google/souper) Bernstein makes a good case for “Death of Optimizing Compilers”, maybe I’m proposing going too much in the other direction?

---

_[View the full topic](https://discourse.julialang.org/t/rethinking-optimization-lower-ok-for-all-julia-code-for-e-g-faster-startup-as-a-default/39843)._