search

haskell-opengl / OpenGLRaw

Haskell bindings to OpenGL (direct C bindings)
http://www.haskell.org/haskellwiki/OpenGL
BSD 3-Clause "New" or "Revised" License
47 stars 19 forks source link

Excessive memory usage of Tokens.hs & Functions.hs #26

Closed serprex closed 9 years ago

serprex commented 9 years ago

GHC 7.10 runs out of memory when building Functions.o when I've given it a gigabyte of swap

I'm willing to split up Tokens.hs & Functions.hs into multiple files (EXT/Functions.hs, NV/Functions.hs) which would then be imported by the modules of those directories rather than Raw.Tokens or Raw.Functions

Raw.Tokens & Raw.Functions would remain, but only with definitions of non-suffix symbols

(There may be some issue since I noticed certain things are interdependent, such as glBufferAddressRangeNV depending on GLuint64EXT, but including an import Graphics.Rendering.OpenGL.Raw.EXT.Tokens should deal with that)

Would such a pull request be accepted, or is there something wrong with this idea? Would it reduce memory usage of ghc?

svenpanne commented 9 years ago

Most of the binding is generated automatically from the OpenGL registry nowadays, including Functions.hs and Tokens.hs, see https://github.com/haskell-opengl/OpenGLRaw/tree/master/RegistryProcessor. Functions.hs corresponds directly to the commands element of the registry, and Tokens.hs to the enums section. Therefore I won't accept patches splitting these files up manually, I'm not even sure if this would reduce GHC's peak memory usage. One way to reduce the module in a structured, automatic way would be combining the foreign imports with the same signature (Edward Kmett's gl package does this IIRC). A minor technical detail would then be coming up with some unique short names for them, just pasting the signature together would result in loooooong names. I'll probably do that one day, but it's not high on my priority list. Patches for that would be welcome, though.

In the short term, I think complaining in the GHC mailing list about the memory consumption is a good way, I think GHC regressed quite a bit in that respect over time. Another point: If you've already got trouble with 1GB, you won't be able to build the documentation, which needs roughly 3GB memory. Regarding that, complain in the lists about haddock, there seems to be a huge space leak in it. The Haskell modules in question are not small (a few MB), but requiring several GB for processing the seems to be a bit too much IMHO.