[MLton] profiler bug?

[Matthew Fluet]

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
>