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.”
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 Bernstein makes a good case for “Death of Optimizing Compilers”, maybe I’m proposing going too much in the other direction?