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@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