[Haskell-cafe] First call to putStr takes far more time than subsequent calls
ben.gunton at gmail.com
Thu Jul 9 21:07:44 UTC 2015
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
On Thu, Jul 9, 2015 at 2:26 PM, Ben Gunton <ben.gunton at 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 at gmail.com>
>> On Thu, Jul 9, 2015 at 4:17 PM, Ben Gunton <ben.gunton at 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
>> allbery.b at gmail.com
>> ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe