Re: [MLton-user] MLton on mswin7 absurdly slow ?

"Wesley W. Terpstra" <[email protected]>
Newsgroups gmane.comp.lang.ml.mlton.devel
Message-ID <[email protected]>
On Mon, Feb 7, 2011 at 3:59 AM, John B Thiel <[email protected]> wrote:

> on a 1.66GHz/1GB ram/mswin7 notebook (well loaded, 12+ apps open)


This sounds like the root of the problem. With 1GB of physical RAM, MLton
decides to use up to 512MB of it. Given you have 12+ apps open, it seems
quite likely that the other apps have a combined working set + pinned pages
exceeding the 512MB. Hence the thrashing.

The policy of "half of physical RAM" is just a rule of thumb. The more
heavily loaded your machine (as a percentage of physical RAM) the less
appropriate it becomes.

It seems there is some runaway allocation with the default options on
> Windows, that unnecessarily overdrives into swap/thrashing.
>

I don't think it's runaway allocation.

If I recall correctly, MLton will use copying collection with a heap size of
twice the live set up until this would exceed the 50% mark. Since we've
established that your hello-world program needs ~100MB, MLton will allocate
400MB. That leaves 600MB for everything else during a garbage collection. I
believe Windows 7 takes somewhere in the ballpark of 200-300MB on its own,
so that leaves just 300MB for your 12+ applications.

So, my suggestions:
1. buy another 1GB of memory which should solve your problem outright (MLton
will leave 1GB to the other 12+ apps, which must be enough since you have
that much memory at the moment)
2. close all the applications you can while working on your MLton-compiled
projects

Keep in mind that for larger projects 100MB will not be enough to compile
them.

_______________________________________________
MLton mailing list
[email protected]
http://mlton.org/mailman/listinfo/mlton
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.