Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve compilation time #458

Open
konsumlamm opened this issue Mar 11, 2023 · 3 comments
Open

Improve compilation time #458

konsumlamm opened this issue Mar 11, 2023 · 3 comments

Comments

@konsumlamm
Copy link
Contributor

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 (Is vector susceptible to the same fusion problems as text? #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
Copy link
Contributor

lehins commented Mar 13, 2023

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 😄

@Shimuuar
Copy link
Contributor

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants