[MLton] profiler bug?
Matthew Fluet
fluet@cs.cornell.edu
Thu, 3 Jun 2004 13:33:32 -0400 (EDT)
I'm not sure what you think is the problem. If you drop all the
flattening passes, then lots of tuples remain in the program. Hence, I
would expect significantly more data to be allocated in the first program.
So, the numbers you show seem perfectly reasonable.
On Thu, 3 Jun 2004, Lukasz S Ziarek wrote:
> In an atempt to get total allocation numbers to compare tuple flattening
> to no tuple flattening (droping the flatten and the three localflatten
> passes in MLton) I have come across the following behavoir when using
> the profiler. This is a clean version of mlton checked out of cvs
> yesterday afternoon (though my version with the implementation of my
> flattener also exhibits this behavoir). Notice the large variation
> in total allocation between the two instances of the checksum benchmark.
> If you run the same executables with @mlton gc-summary -- the numbers do
> not match up.
>
> -Luke
>
> skavena 260 $ ./mlton -drop-pass flatten -drop-pass localFlatten1
> -drop-pass localFlatten2 -drop-pass localFlatten3 -profile alloc
> checksum.batch.sml
> skavena 261 $ ./checksum.batch
> skavena 262 $ ./mlprof checksum.batch mlmon.out
> 45,010,009,860 bytes allocated (1,252 bytes by GC)
> function cur
> ----------------- ------
> fold.loop 100.0%
> Main.doit 0.0%
> <main> 0.0%
> <gc> 0.0%
> MLtonProcess.exit 0.0%
> PosixIO.isReg 0.0%
>
>
>
> skavena 263 $ ./mlton -profile alloc checksum.batch.sml
> skavena 264 $ ./checksum.batch
> skavena 265 $ ./mlprof checksum.batch mlmon.out
> 10,008,856 bytes allocated (1,252 bytes by GC)
> function cur
> ----------------- -----
> Main.doit 99.9%
> <main> 0.1%
> <gc> 0.0%
> PosixIO.isReg 0.0%
> MLtonProcess.exit 0.0%
>
>
> _______________________________________________
> MLton mailing list
> MLton@mlton.org
> http://www.mlton.org/mailman/listinfo/mlton
>