Opened 10 years ago

Closed 7 years ago

Last modified 7 years ago

#3897 closed bug (fixed)

reading a large String as Double takes too long

Reported by: maeder Owned by:
Priority: low Milestone: 7.4.2
Component: Prelude Version: 6.12.1
Keywords: Cc:…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time performance bug Test Case:
Blocked By: Blocking:
Related Tickets: 5688 Differential Rev(s):
Wiki Page:


Prelude> :set +s
Prelude> read "1e1000000" :: Double
(0.46 secs, 8977756 bytes)
Prelude> read "1e1000000000" :: Double

The final call takes up all memory and does not terminate

Change History (12)

comment:1 Changed 9 years ago by igloo

Milestone: 6.14.1
Prelude> (1e1000000000 :: Double) `seq` ()
<interactive>: out of memory (requested 537919488 bytes)

comment:2 Changed 9 years ago by

Cc:… added

read "1eN" :: Double requires calculating 10N :: Rational. For N of large absolute value, that is slow and memory intensive.

It could be solved by changing the Lexeme type, replacing the Rat Rational constructor with e.g. RatExp Rational (Maybe Integer) and letting the read instance decide whether to do it at all. That would however make the Read instances more complicated and slower for more reasonable input strings (how much?). Is it worth doing it?

comment:3 Changed 9 years ago by igloo


comment:4 Changed 9 years ago by igloo


comment:5 Changed 8 years ago by maeder

I've noticed the same problem for the float parsers in Text.ParserCombinators.Parsec.Token.exponent' (or Text.Parsec.Token) that use 10^e to compute the factor. Using '10e' instead (hopefully) solved the problem in my Text.ParserCombinators.Parsec.Number module (function exponentValue) from

comment:6 Changed 8 years ago by maeder

It does not even need an undecidable type system for compilation to fail. The following source is enough:

main = print 1E1000000000

Using Rational or Integer is a bad idea to compute the exponent factor (with "" or ""), in particular since the exponent notation is not supported for these types.

comment:7 Changed 8 years ago by maeder

Architecture: x86Unknown/Multiple
Operating System: LinuxUnknown/Multiple
Type of failure: Runtime performance bugCompile-time performance bug

The relevant source seems to be the module Text.Read.Lex (function valueFracExp and valExp in lexDecNumber) of the base package

comment:8 Changed 8 years ago by igloo


comment:9 Changed 8 years ago by gracjan

Patch in #5688 resolves also this issue.

comment:10 Changed 8 years ago by igloo

Priority: normallow

comment:11 Changed 7 years ago by pcapriotti

difficulty: Unknown
Resolution: fixed
Status: newclosed

This is indeed fixed both in 7.4 and HEAD.

comment:12 Changed 7 years ago by maeder

I've created a new ticket #7042 if you think this one is closed

Note: See TracTickets for help on using tickets.