On Monday, 4 July 2016 at 01:57:19 UTC, Hiemlick Hiemlicker wrote:
version(Windows)
void main()
{
import std.random;
while(getchar() != EOF)
{
auto x = new int[std.random.uniform(1000000, 10000000)];
writeln("--------");
bThread.Now();
}
}
more or less, ends up with a huge amount of page faults and a
several hundred MB commit size(hold enter down a bit). I'm
trying to understand this. Is that normal behavior for normal
programs(haven't tried it with a similar C++ example though).
The PF's are most likely due to default initialization, so you
may not see those in a C++ equivalent (or, actually, the exact
equivalent would be to initialize the array as well, in that case
you'd get PF's too). If you've determined default initialization
is causing performance problems in a hot piece of code, D
provides facilities to disable it.
I realize the GC has to do some work and all that but the
program only has a working set of a few MB yet a commit of 10
times that.
Is commit size essentially "touched" memory but really doesn't
mean much to overall free ram?(can other programs use it at
some point)?
Strictly speaking there's no relation between commit size and
RAM, from your application's POV there's only the virtual address
space. Committed memory can be paged to disk if the OS determines
your application isn't actively using certain pages.
We know the program is not using more than 10MB
It's an array of ints, so you'll have to multiply that by four ;)
of extra memory(since x is local)... so I'd only expect the
footprint to be a max of around 15-20MB. not 150MB+(depends on
how fast and long you hit enter).
Keeping memory usage to an absolute minimum would mean the GC has
to do a collection on every allocation. As a very coarse rule of
thumb, expect a GC heap (not just the D GC) to be about 1.5 to 2
times as large as strictly necessary. This is to reduce the
amount of collections. Since your example is doing nothing but
hammering the GC I'm not surprised the heap is a bit larger than
that.
