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