Hi, > > > > On 17/06/16 10:36, Joachim Breitner wrote: > > > Ok. But the module where it stops is a huge one: > > > http://hackage.haskell.org/package/OpenGLRaw-3.2.0.0/src/src/Graphics/GL/Functions.hs > > > > > > I would not be surprised if the compiler starts swapping and gets > > > really slow. I did some bench-marking, both on my machine (amd64) and on harris (armhf). It seems that the problem lies in GHC's LLVM code generator. Below are the results of 'cabal build -j1'. I expect building the Debian package to take twice as much time, since it also builds the profiling version of the library. | Original | Modified | -------------------------------------------- amd64 + native | 2m41.799s | 1m58.048s | amd64 + LLVM | 67m18.889s | 9m10.600s | armhf + LLVM | 611m34.818s | 233m35.556s | The 'Modified' column refers to a modified version of the package where the 'Functions' module has been split to 80 smaller ones. For anyone interested, I used the code from here[1] to achieve that. I see the following options: * Suggest that the authors of OpenGLRaw split the 'Functions' module. This will certainly improve the compilation time, but I am not sure it will be enough for the package to be built on our buildds. * Open a bug report against GHC's LLVM code generator. It is expected to be slower than the native one, but it feels like there is a bug here. * Remove haskell-openglraw from arm* architectures. These architectures use the LLVM code generator. What do you suggest? [1] https://github.com/iliastsi/OpenGLRaw/commit/df9c1b7e3f941a3d -- Ilias
Attachment:
signature.asc
Description: PGP signature