[Haskell-cafe] First call to putStr takes far more time than subsequent calls

Ben Gunton ben.gunton at gmail.com
Fri Jul 10 01:34:31 UTC 2015

When a module is imported, or used for the first time, are there things
that are not fully evaluated?

I see the same thing you do with the Data.Fixed methods (nice work by the
way!), but I also see similar (albeit less drastic) behaviour with other
datatypes, including some custom ones. It just always seems like the first
call to a modules method is always slower than subsequent calls. But I
can't for the life of me figure out why...

On Thu, Jul 9, 2015 at 5:45 PM, Roman Cheplyaka <roma at ro-che.info> wrote:

> This is a nice puzzle. However, I don't think it's related to IO.
> So far I've traced this to Data.Fixed methods. If you add
>   evaluate $ floor (2/1 :: Fixed E12)
> before the loop, you'll find that the delay decreases significantly
> (although doesn't vanish entirely).
> How is this related to forcing a time value? Well, UTCTime represents
> the time of day as Fixed E12, and when you're evaluating the result of
> getCurrentTime, you're calling those methods, (/) and floor.
> Using other methods of Fixed E12 before the loop, or replacing E12 with
> E9, kills or at least hurts the effect.
> There might be some thunks referenced directly or indirectly by those
> methods, possibly involving specialization, but I don't see it so far.
> I'll let someone else to take it from here.
> On 10/07/15 00:07, Ben Gunton wrote:
> > Here is the same thing with no console usage, just forcing the time
> > value. The first-iteration-delay seems to happen at the first IO-ish
> > thing being evaluated.
> >
> > http://lpaste.net/136254
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150709/8128d423/attachment.html>

More information about the Haskell-Cafe mailing list