A quick question. After watching the DLang 2017 conference, there was mention about the runtime optimizing that is going on. Will this have a impact on the default memory usage (on small projects )?

On Tuesday, 23 May 2017 at 15:36:45 UTC, Wulfklaue wrote:
> A quick question. After watching the DLang 2017 conference, there was mention about the runtime optimizing that is going on. Will this have a impact on the default memory usage (on small projects )?

Why does even a simple empty:

void main()
{
while(true)
	{}
}

Great ... accidentally pressed send.

So my question was:

Why does even a simple empty empty statement like this, compiled with DMD, show under windows a almost 1.7MB memory usage?

void main()
{
  while(true){}
}

The same in C/C++ is simply 0.1MB. This is why i asked the question if the runtime is somehow responsible?

On Wednesday, 24 May 2017 at 07:54:04 UTC, Wulfklaue wrote:
> Great ... accidentally pressed send.
>
> So my question was:
>
> Why does even a simple empty empty statement like this, compiled with DMD, show under windows a almost 1.7MB memory usage?

Because the garbage collector (GC) allocates a sizable chunk of memory from the operating system at program startup, from which it then in turn allocates memory for you when you use things like dynamic closures, `new XYZ`, etc.

>
> void main()
> {
>   while(true){}
> }
>
> The same in C/C++ is simply 0.1MB. This is why i asked the question if the runtime is somehow responsible?

Yes, it is. It is the price we have to pay for having a GC. If the overhead bothers you, you might want to compare it with other garbage collected languages (such as Go).

PS: This might belong in Learn, instead of General.

On Wednesday, 24 May 2017 at 10:34:02 UTC, Moritz Maxeiner wrote:
> Because the garbage collector (GC) allocates a sizable chunk of memory from the operating system at program startup, from which it then in turn allocates memory for you when you use things like dynamic closures, `new XYZ`, etc.
>
Well, that sounds just silly.

> Yes, it is. It is the price we have to pay for having a GC. If the overhead bothers you, you might want to compare it with other garbage collected languages (such as Go).
>

Go is a different animal because of the concurrent GC.

On Wednesday, 24 May 2017 at 14:26:42 UTC, Wulfklaue wrote:
> Well, that sounds just silly.

You can bypass it by doing an `extern(C)` main in D... but really, the 1 MB preallocation isn't much for small programs and for larger programs it will be used anyway, so you aren't actually losing anything.

On Wednesday, 24 May 2017 at 14:26:42 UTC, Wulfklaue wrote:
> On Wednesday, 24 May 2017 at 10:34:02 UTC, Moritz Maxeiner wrote:
>> Because the garbage collector (GC) allocates a sizable chunk of memory from the operating system at program startup, from which it then in turn allocates memory for you when you use things like dynamic closures, `new XYZ`, etc.
>>
> Well, that sounds just silly.

Before making such judgement you may want to consider the cost of system calls, how memory fragmentation affects a conservative GC, and why we cannot have a different kind of GC without unacceptable trade offs.

>
>> Yes, it is. It is the price we have to pay for having a GC. If the overhead bothers you, you might want to compare it with other garbage collected languages (such as Go).
>>
>
> Go is a different animal because of the concurrent GC.

Not the point.

On 5/24/17 6:34 AM, Moritz Maxeiner wrote:
> On Wednesday, 24 May 2017 at 07:54:04 UTC, Wulfklaue wrote:
>> Great ... accidentally pressed send.
>>
>> So my question was:
>>
>> Why does even a simple empty empty statement like this, compiled with
>> DMD, show under windows a almost 1.7MB memory usage?
>
> Because the garbage collector (GC) allocates a sizable chunk of memory
> from the operating system at program startup, from which it then in turn
> allocates memory for you when you use things like dynamic closures, `new
> XYZ`, etc.

Note, you can usually allocate close to the entire address space, but if you never access it, it's not actually used in the RAM of your computer. So it's possible D is pre-allocating a bunch of space from the OS, but it's not actually consuming RAM.

However, I don't know the true answer. It may actually be 1.7MB of "bookeeping", but I doubt that. The GC structures aren't *that* large, I'd expect at most 10 pages for the small-chunk bins, and a few more for bits. Possibly the static segment is large, but 1.7 MB is around 400+ pages. It's likely that most of that is just a pre-allocation of a large continuous space "just in case", but it's not actually wired to RAM yet.

-Steve

On Wednesday, 24 May 2017 at 15:07:42 UTC, Steven Schveighoffer wrote:

> However, I don't know the true answer. It may actually be 1.7MB of "bookeeping", but I doubt that...

It's a bit of pre-allocation and some internal bookkeeping.

void main()
{
    import std.stdio;
    import core.memory;
    writeln(GC.stats);
}

//   used, free
Stats(256, 1048320)

The remaining .7Mb could probably be attributed to some internal data structures.

On Wednesday, 24 May 2017 at 15:22:55 UTC, Stanislav Blinov wrote:
> It's a bit of pre-allocation and some internal bookkeeping.
>
> void main()
> {
>     import std.stdio;
>     import core.memory;
>     writeln(GC.stats);
> }
>
> //   used, free
> Stats(256, 1048320)
>
> The remaining .7Mb could probably be attributed to some internal data structures.

Thanks, it places D in a better limelight.

I assume that from the 0.7MB, part of it is the executable ( 0.24MB ) that is loaded into memory.

+1 for the answer. :)