This is almost certainly garbage collection (GC), likely of a higher generation (i.e. a major GC). These can cause significant pauses in cases where lots of long-lived garbage is being created.
If you wanted to see this happening, you can make a quick executable and check:
Start with tmp.hs
:
module Main where
fibs = 1:1:zipWith (+) fibs (tail fibs)
main = print $ fibs !! 100000
Compile with ghc -rtsopts tmp.hs
Run with ./tmp +RTS -s
454,847,088 bytes allocated in the heap
230,044,816 bytes copied during GC
4,291,856 bytes maximum residency (226 sample(s))
18,080,904 bytes maximum slop
56 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 676 colls, 0 par 0.07s 0.07s 0.0001s 0.0023s
Gen 1 226 colls, 0 par 0.27s 0.28s 0.0012s 0.0084s
INIT time 0.00s ( 0.00s elapsed)
MUT time 0.14s ( 0.14s elapsed)
GC time 0.34s ( 0.35s elapsed)
EXIT time 0.00s ( 0.00s elapsed)
Total time 0.48s ( 0.49s elapsed)
%GC time 71.0% (71.6% elapsed)
Alloc rate 3,303,664,644 bytes per MUT second
Productivity 28.9% of total user, 28.8% of total elapsed
This signifies 676 minor garbage collections and 226 major, with 2nd generation collections taking ~12x more time to complete than minor. Note that this was only the hundred thousandth number, so pauses may be longer at higher numbers. Also note that GHCI is an interpreter, so there will be associated slowdowns.
As an aside, I did try compiling and running this example with optimization turned on. There was no appreciable difference in time, and the memory/GC characteristics were almost identical.