Bulat Ziganshin wrote:
the same is for Int32 (and i think other fixed-width integrals). i just noticed that one simple loop in my program allocates 2.5 times more data and works 2 times slower when loop variable switched from Int to Int32
There's no reason that Int32 should be slower than Int, unless there are specialisations for Int but not Int32. This ceratinly isn't related to the issues that affect enumerations, incedentally. If you have Int code that is a lot slower when you switch to Int32, and you aren't using any overloading function that have specialisations for Int, then it could be a performance bug. Please submit a report.
it is very likely that Joels unpickling code suffers from this problem - all data in his program are defined with fixed-width types
it is also likely that HashTable package suffers from this problem - it uses Int32 to represent hash keys
Highly unlikely, I've peered at the code generated for HashTable and it doesn't have any issues like this.
btw, i just noticed one more "feature" that is documented nowhere - (explicit) inlining of default class methods doesn't work, so that:
class C where f :: ... f = ... {-# INLINE f -#}
instance C T where
doesn't inline `f`, so i need to switch to:
class C where f :: ...
instance C T where f = ... {-# INLINE f -#}
This should work, and indeed I just tried it on a small example and it seems to work fine. Can you provide a repro case? Cheers, Simon