input-output-hk
Performance of hsc2hs
hsc2hs has an --via-asm flag. That will cause it to use its AT&T Asm parser to figure out the size of constants, ... once essential issue here is that we generate a single c file for each constant. It would be better if we generated all constants (with some identification flag) in one file, and only parsed that file. I believe this would give hsc2hs a considerable performance boost.
This is especially pronounced if a windows cross compiler builds the Win32 package which has lots of hsc2hs usage.
I'm relatively unfamiliar with hsc2hs. How is haskell.nix in a position of responsibility here? This sounds like an hsc2hs issue.
@ElvishJerricco right, this is not strictly a haskell.nix issue. As the haskell.nix issue tracker is currently the kitchen sink for us. I've just posted it here. See also the Projects tab.
@angerman I'm exposed to this issue since I use several libraries that use hsc2hs heavily.
I'd like to fix this - any tips getting started?
- How can I fork
hsc2hsand havehaskell.nixuse my version? - Are there any more details/tips you can give about your proposed solution?
This issue is a slight annoyance to me. I have a few libraries (sdl2, sdl-gpu, and Win32) that end up rebuilding somewhat often and experience this issue.
I had a wild idea, but I don't know enough of hsc2hs to confidently say it would work:
What if when x-compiling to Windows, we ran the mingwW64 version of hsc2hs under wine (similar to what is done in the iserv wrapper). Then it could run in "direct" mode and bypass this issue altogether. I'm guessing more work may also need to be done to make sure hsc2hs is using the correct C compiler as well, but it feels like we'd have access to that since we are generating valid target code at the end of the day.
I assume the same trick could work for other cross targets with enough work to emulate hsc2hs's work on the host.
The idea in the OP about generating one file also seems promising (and not that hard to do - hsc2hs is a pretty straightforward Haskell program).
Either way, it feels like I would be able to just set the --with-hsc2hs cabal flag in my code's haskell-nix.defaultModules to try out my custom hsc2hs (if I understand the attribute correctly).
Was there any update to hsc2hs lately? I'm noticing that hsc2hs is substantially faster when x-compiling to mingwW64 now.
Was there any update to
hsc2hslately? I'm noticing thathsc2hsis substantially faster when x-compiling to mingwW64 now.
Did you change compiler versions? Hsc2hs is usually shipped with GHC and the one package that's really slow is the Win32 package.
I bumped to 9.2.8.
Win32 is slow, but sdl-gpu (library I wrote bindings for which uses a lot of hsc2hs) was also pretty slow (like walk away and come back slow) but now it is fine. Maybe this is just faulty memory on my part though.