3 ms·
Code size is pretty big currently indeed. The highest priority is to make sure that we get all required patches to support GHCJS merged into GHC, before 7.8.1 i
by luite 13y ago
Code size is pretty big currently indeed. The highest priority is to make sure that we get all required patches to support GHCJS merged into GHC, before 7.8.1 is out. GHCJS is a standalone, cabal installable compiler (it uses the GHC API), but some features, like the "foreign import javascript" FFI need some minor changes in GHC itself.
We haven't really spent much time optimizing for code size yet, and there's still lots of low hanging fruit. We will never reach 3kB minified though, for example the JSBN library (that we use to implement Integer) alone is a lot bigger than that.
The GHCJS linker does tree shaking: Only functions that are reachable from main are included in the result. We have some plans to extend this a bit, an old version already had incremental loading, but that has not yet been implemented for the new code generator.
- chongli 13y ago>The GHCJS linker does tree shaking Ahh, so does this mean we can shake out entire libraries like JSBN if we avoid using Integer?
- luite 13y agoIf you're really careful and not use anything from base that might use an Integer ;) Currently non-Haskell dependencies are managed per package, so if anything from integer-gmp is linked, it will include the whole JSBN. If you want to weed out the unused JSBN part, you can use closure compiler (although the new code generator will probably still have a few incompatibilities with it).
- chongli 13y agoOh, so does that mean I can't do anything that uses the Integral class, for example? Even if I make sure all my types are Ints?
- luite 13y agoYou can use the Integral class (when compiling, the instance gets converted to an extra dictionary argument, if you never use the instance the dictionary will be unreachable) But Integer is really hard to avoid in general, for example the Show instance for Double depends on it.