Compile times and memory usage - remove O2 optimization option?

[minad]

I have problems compiling aeson on systems with low memory. Also compile times are very long. This is probably due to the O2 optimization flag or due to many INLINE pragmas. Most packages do not specify the optimization mode themselves. Would it make sense to remove the O2 optimization option or at least add a flag to disable it?

[phadej]

This is one reason I'm working on #766, it might be (I'm quite confident) that -O2 doesn't bring real benefit.

I'd rather not introduce yet another flag, but remove fast we have already.

[minad]

@phadej Thank you, that's great. I have the feeling this package needs an overall cleanup. For example it could be the time to drop many of the compatibility dependencies etc. Is there a reason to keep this package working with ancient GHC versions?

[phadej]

Is there a reason to keep this package working with ancient GHC versions?

Is there reason not to?

The #ifdefs are mostly limited to TH code now. For example I think we can drop pre primitive-0.7 support now.

[bergmark]

We recently dropped support for GHC < 7.8. The compat dependencies mainly affect older GHCs so I don't think there's any harm in keeping them. Rather, we make it much simpler to keep supporting older GHCs when new ones are released, and we can continue the informal policy to only drop support once we become blocked on enhancements. E.g. the dependencies listed at http://hackage.haskell.org/package/aeson look scary but on GHC 8.10 you won't need to install most of them. @RyanGlScott has done amazing work with e.g. base-compat-batteries so it saves us a lot of effort.

We also have #529 which we've worked on but can be continued.

[phadej]

I'd say with #791 the #529 could be closed.

The remaining CPP is mostly contained in TH module, or is very local.

[minad]

@bergmark I agree, it is better to use compatibility libraries than duplicating the work yourself. However after a some time it feels that a lot of cruft accumulated. As you say - the hackage dependency listing looks scary.

@phadej

Is there reason not to?

The reason I am seeing is maintainability/avoiding CPP. But this is just personal preference.

[phadej]

-O2 is removed in master. People who really need it can add

package aeson
  ghc-options: -O2

to their cabal.project