Improve compilation time

[konsumlamm]

I was wondering if it is possible to improve the compilation time for vector. On my machine, compiling it from scratch currently takes about 1.5 minutes (1 m 35 s), which I feel like is too long. For comparison, containers takes 45 seconds and unordered-containers takes 23 seconds. Yes, I know, cabal caches the build, but it's still annoying (you still have to compile it when switching to a new GHC version, contributing to vector, in CI, when non-Haskell people want to install a tool using vector,...).

Some ideas that might help to decrease compilation time:

• disable implicit fusion (#457)
• split vector into several smaller packages (e.g. vector-core, vector-storable, vector-unboxed), so that users only have to depend on the parts they actually use (vector would stay the same, so people could just keep using it)
• don't use -O2 (find out which flags significantly improve performance and only enable those)
• reduce inlining (this is probably hard without also reducing performance)
• avoid redefinitions for specialization (this would be a breaking change, but idk how big the impact would be)

I'm curious how realistic you find my ideas and if you have other ideas to improve compilation time.

[lehins]

All of the points you mention (except splitting into separate packages) will have runtime performance implications. I don't think this work is really worth the effort in order to gain a few seconds during compilation. Mind you, the effort to address any of the points you mention would be huge. That being said, if you have loads of free time and you can find how to speed up compilation without loosing performance, don't let me stop you :smile:

[Shimuuar]

Out of curiosity I tested what will happen if one to remove all INLINE. Compilation time went 91s → 34s. And benchmarks suffered 150-200× slowdown. After all in order to get performance one needs specialization and only way to get specialization is to inline everything

[konsumlamm]

I tried disabling optimizations and avoiding redefinitions by just reexporting the Generic variants.

original: 1m26s without optimizations: 1m10s without redefinitions (but with optimizations): 52s

The benchmarks stayed about the same. Without redefinitions, I just had to enable FlexibleContexts. Even without optimizations (of the library, I still enabled them in the benchmark), the times didn't change, so maybe there is a mistake in my method, or the inlining makes the optimization level irrelevant.