[Haskell-cafe] Lack of inlining -> slow parsing with Data.Binary
ekirpichov at gmail.com
Tue Jan 6 15:05:49 EST 2009
Thanks; I'm using GHC 6.10.1 and the latest binary now, and things get
inlined perfectly well.
Anyways, the main bottleneck turned out to be the performance of
zip-archive , which is now (since 1-2 days ago) ~25x better, and now
the Haskell version is about just 2.5x slower than the Java one, and
I'm quite satisfied with this result and with the process that led to
(Surprisingly, the bottleneck is now in a conversion from a linked
list to an STArray)
In case anyone is interested, here are the results of my hacking:
- http://hackage.haskell.org/cgi-bin/hackage-scripts/package/digest -
bindings to crc32 and adler32 from zlib
- updated version of zip-archive that uses digest and doesn't suffer
from a crc32 bottleneck
- the very utility in question (the classfile searcher)
All in all, Haskell rocks :)
2009/1/6 Don Stewart <dons at galois.com>:
>> I'm parsing Java classfiles with Data.Binary, the code is here:
>> The problem is that the resulting code parses rt.jar from JDK6 (about
>> 15K classes, 47Mb zipped) in 15 seconds (run the program with main
>> -mclose rt.jar, for instance), which is 10 times slower than my Java
>> version of the same code.
>> I compile the program with -O2 ; I tried -ddump-inlinings and it turns
>> out that my readByte/readWord16/readWord32 functions don't get
>> inlined, despite being simply aliases for 'get::Get WordXX'; so, in
>> places where my Java version does a pointer access (after being
>> JIT-compiled), the Haskell version does two function calls.
>> What can be the reason of this lack of inlining? Or how do I
>> understand the output of -ddump-inlinings?
> Which version of GHC and Data.Binary are you using?
> If using 6.8.x, use the previous Data.Binary release. If using 6.10.x,
> use the latest.
> -- Don
More information about the Haskell-Cafe