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

On Thu, Jul 9, 2015 at 2:26 PM, Ben Gunton <ben.gunton@gmail.com> wrote:
The thing is, if I switch the "putStr """ in the replicateM to "evaluate $ force t1", the first iteration still takes way longer. Are there things to setup even with that? Is there a way to pre-setup all the things that need to be setup?

This is also on Linux, with GHC 7.10.1, and no optimizations.

On Thu, Jul 9, 2015 at 2:24 PM, Brandon Allbery <allbery.b@gmail.com> wrote:
On Thu, Jul 9, 2015 at 4:17 PM, Ben Gunton <ben.gunton@gmail.com> wrote:
In this example, the first putStr inside the replicateM_ takes far longer than subsequent putStrs. If I add in a putStr at the top (the commented line), each iteration takes the same. (Though I presume I just shifted the long execution to the putStr on top).

If I had to guess, delayed setup of the Handle associated with stdout. This will include setting up buffering (including querying the OS to find out whether output is a tty-like device or not, so as to enable or disable block buffering; note that this may be especially expensive on Windows, where there is IIRC no simple way to determine whether running in e.g. a cmd.exe window or not, as the OS has no concept of pseudo-ttys); also, setting up output encoding and such. Probably also other details.

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b@gmail.com                                  ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net