Significant compilation slowdown when using Data.CaseInsensitive.mk
Hi, I've recently run into an issue whereby changing textual case comparison to use the Data.CaseInsensitive.mk http://hackage.haskell.org/package/case-insensitive-1.2.0.3/docs/Data-CaseIn... smart constructor causes substantial differences to outputted core language and a related compilation speed regression. The code which seems to cause this is here: https://github.com/brendanhay/amazonka/blob/release/0.1.4/core/src/Network/A... With the downstream project having about 68 call sites for the above function starting here: https://github.com/brendanhay/amazonka/blob/release/0.1.4/amazonka-ec2/gen/N... For comparison, the previous version used Attoparsec.Text.takeText http://hackage.haskell.org/package/attoparsec-0.12.1.2/docs/Data-Attoparsec-... and Text values. Here are some hand wavy points of interest: * Before (Case Sensitive) Function: takeText = Attoparsec.Text.takeText Time (real): 2m27.735s amazonka-ec2/gen/Network/AWS/EC2/Types.hs (simpl): {terms: 242,688, types: 310,463, coercions: 31,215} * After (Case Insensitive) Function: takeCI = Data.CaseInsensitive.mk <$> Attoparsec.Text.takeText Time (real): 11m31.937s amazonka-ec2/gen/Network/AWS/EC2/Types.hs (simpl): {terms: 1,384,779, types: 465,656, coercions: 33,510} I'm finding the outputted core rather unwieldy to analyse, but the main difference seems to be the inclusion of huge swathes of case statements like: https://gist.github.com/brendanhay/5a57f073d5a7d196a1ad It would be appreciated if someone could help me to understand in simple terms why the use of case-insensitive causes this.
Apologies, I should have used SHA references in the links:
The code which seems to cause this is here:
https://github.com/brendanhay/amazonka/blob/release/0.1.4/core/src/Network/A... https://github.com/brendanhay/amazonka/blob/049fab83dd71e3f2e8aa5643902f95e8...
With the downstream project having about 68 call sites for the above function starting here:
https://github.com/brendanhay/amazonka/blob/release/0.1.4/amazonka-ec2/gen/N...
https://github.com/brendanhay/amazonka/blob/04f620d3e01a05c30db99afa07a84d07...
On 6 January 2015 at 20:07, Brendan Hay
Hi,
I've recently run into an issue whereby changing textual case comparison to use the Data.CaseInsensitive.mk http://hackage.haskell.org/package/case-insensitive-1.2.0.3/docs/Data-CaseIn... smart constructor causes substantial differences to outputted core language and a related compilation speed regression.
The code which seems to cause this is here:
https://github.com/brendanhay/amazonka/blob/release/0.1.4/core/src/Network/A...
With the downstream project having about 68 call sites for the above function starting here:
https://github.com/brendanhay/amazonka/blob/release/0.1.4/amazonka-ec2/gen/N...
For comparison, the previous version used Attoparsec.Text.takeText http://hackage.haskell.org/package/attoparsec-0.12.1.2/docs/Data-Attoparsec-... and Text values.
Here are some hand wavy points of interest:
* Before (Case Sensitive) Function: takeText = Attoparsec.Text.takeText Time (real): 2m27.735s amazonka-ec2/gen/Network/AWS/EC2/Types.hs (simpl): {terms: 242,688, types: 310,463, coercions: 31,215}
* After (Case Insensitive) Function: takeCI = Data.CaseInsensitive.mk <$> Attoparsec.Text.takeText Time (real): 11m31.937s amazonka-ec2/gen/Network/AWS/EC2/Types.hs (simpl): {terms: 1,384,779, types: 465,656, coercions: 33,510}
I'm finding the outputted core rather unwieldy to analyse, but the main difference seems to be the inclusion of huge swathes of case statements like: https://gist.github.com/brendanhay/5a57f073d5a7d196a1ad
It would be appreciated if someone could help me to understand in simple terms why the use of case-insensitive causes this.
participants (1)
-
Brendan Hay