Reversed profile stack
Summary
Here are two extracts from the same profiling report file:
parseIntegral Trace.Internal src/Trace/Internal.hs:(101,56)-(104,61) 622 3871885 18.7 16.8 80.8 71.1 4084 3057274056
eventParser Trace src/Trace.hs:(343,87)-(374,9) 623 1930555 4.3 5.7 60.5 54.3 947 1027402080
parseFieldKind Trace src/Trace.hs:(454,9)-(468,48) 636 1936408 0.8 0.6 0.8 0.6 172 107905344
And
eventParser Trace src/Trace.hs:(343,87)-(374,9) 626 0 0.0 0.0 0.0 0.0 0 0
fieldParsers Trace src/Trace.hs:347:51-128 628 16 0.0 0.0 0.0 0.0 0 26880
parseFieldKind Trace src/Trace.hs:(454,9)-(468,48) 630 98 0.0 0.0 0.0 0.0 0 3472
parseIntegral Trace.Internal src/Trace/Internal.hs:(101,56)-(104,61) 635 59 0.0 0.0 0.0 0.0 0 0
The 2nd one shows the stack in the expected order. parseIntegral
is a simple routine that does not make any direct or indirect call to eventParser
. The only way I can see it could end up running eventParser
code is through a thunk, but the documentation[1] explicitly mentions this case as being handled. Upon forcing, the stack attached to the thunk should be restored and the current cost center should therefore change to the one that created the thunk, not the one forcing it.
Steps to reproduce
Compile with -prof
and -fno-prof-auto
, -fno-prof-cafs
(this is done via stack though, so other options might be included by it).
Expected behavior
My understanding is that the first stack snippet should not exist in the profile report.
Environment
- GHC version used: 8.10.2
Optional:
- Operating System: Archlinux
- System Architecture: x86_64