-
-
Notifications
You must be signed in to change notification settings - Fork 19
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
Binary size with stratosphere #95
Comments
The reason we have a big sum type and a single package is so we can read template files with types as well as write them. I'm considering abandoning that requirement though, since I'm not sure anyone does that very often. I'd love to retain some way to read templates in a type-safe way though, since splitting up this package could have a lot of benefits (compile time of dependencies, for one). Currently the constructors for the big sum type have a type Another idea is to hard-code GHC options in the cabal file to not run optimizations and focus on saving on binary size. By default it will use I'm sure this is all technically possible (and probably not even that hard), but I'll let other chime in with thoughts. I'm curious about your use case. Do you have a distributed application that generates CloudFormation templates via |
Hi @jdreaver , thank you very much for you detailed answer. Now I understand the reasoning behind the big sum type, thank you. I understand that being able to read the template files can be useful; so it is totally up to you to decide :). You are right, the approach you mentioned would work perfectly for me. But then I have no idea how you'd implement the read logic there. I tried compiling As I said, I know that this issue is not a priority, and I am perfectly fine if you decide not to action it; thank you for spending your time on it :). Here is my usage of stratosphere, specifically this function. What that library does is that it uploads itself to S3 and creates a small stack using My problem there is that binary size is a bit important for me because:
So having a small binary directly results on getting your result faster. Technically I don't use |
Yeah I'm planning on removing that. I'll definitely need to do it in another PR and solicit feedback from folks, plus use it on all of our templates at Freckle to see how painful migrating is. |
Recently I noticed that Stratosphere was responsible for a large percentage of my binary size.
For example, below executable is 3.4 MB (with statically linked haskell libraries as in default GHC); but if you comment out the line which puts Stratosphere to the executable, it immediately becomes 36 MB.
I am aware that for most of the use cases this is not a big issue, but I am working on a distributed application that I need to share the binary and this is my main problem with this otherwise excellent library.
I think one of the reasons might be the way
ResourceProperties
is structured. Since it is a sum type of every possible resource, just depending on it pulls the whole thing to the executable. I can not really think of a solution, but maybe using a typeclass based approach one can just import the resources they need (likeamazonka
, I think) or we can have an intermediate data type that we first convert the parameters to.The text was updated successfully, but these errors were encountered: