On Wednesday, 23 April 2014 at 19:54:29 UTC, Nordlöw wrote:
>> tl;dr: allocation is a critical speed issue with dmd. Using the bump-pointer method is very fast, and it matters.
>
> What about packing DMD structure members such as integers and enums more efficiently?
>
> We could start with making enums __attribute__((packed)). Is there any free static/dynamic tool to check for unexercized bits?
>
> How does Clang do to save so much space compared to GCC? Do they pack gentlier or use deallocation?
>
> A much higher-hanging fruit is to switch from using pointers to 32-bit handles on 64-bit CPUs to reference tokens, sub-expressions etc. But I guess that is a big undertaking getting type-safe and may give performance hits.

Maybe we should investigate where the memory is going first before planning our attack :-)

> Maybe we should investigate where the memory is going first before planning our attack :-)

I agree. Tool anyone?

> I agree. Tool anyone?

https://stackoverflow.com/questions/23255043/finding-unexercised-bits-of-allocated-data

Massif may give some clues.

On 23 April 2014 21:55, "Nordlöw" <digitalmars-d@puremagic.com> wrote:
>> Maybe we should investigate where the memory is going first before planning our attack :-)
>
>
> I agree. Tool anyone?

I'm using valgrind - may take a while to process and merge them all. I'll post an update in the morning.

On Wednesday, 23 April 2014 at 20:04:09 UTC, Peter Alexander
wrote:

> Maybe we should investigate where the memory is going first before planning our attack :-)

FWIW one hint might be found in the DCD project found here:

https://github.com/Hackerpilot/DCD/

In that project compiling the lexer.d file causes a massive
increase in compiler memory usage.

More details found here:

https://github.com/Hackerpilot/DCD/issues/93

NOTE: That was DMD running on a 32 bit Windows XP machine.

On Wednesday, 23 April 2014 at 23:19:20 UTC, Jussi Jumppanen wrote:
> In that project compiling the lexer.d file causes a massive
> increase in compiler memory usage.

The code is actually located here:

https://github.com/Hackerpilot/Dscanner

If you want to make DMD cry, compile it with "-O -inline -release".

Am Wed, 23 Apr 2014 21:23:17 +0400
schrieb Dmitry Olshansky <dmitry.olsh@gmail.com>:

> 23-Apr-2014 20:56, Daniel Murphy пишет:
> > "Dmitry Olshansky"  wrote in message news:lj7mrr$1p5s$1@digitalmars.com...
> >> At a times I really don't know why can't we just drop in a Boehm GC (the stock one, not homebrew stuff) and be done with it. Speed? There is no point in speed if it leaks that much.
> >
> > Or you know, switch to D and use druntime's GC.
> 
> Good point. Can't wait to see D-only codebase.

Hmm. DMD doesn't use a known and tried, imprecise GC because it is a lot slower. How is DMD written in D using the druntime GC going to help that ? I wondered about this ever since there was talk about DDMD. I'm totally expecting compile times to multiply by 1.2 or so.

-- 
Marco

On 23/04/14 08:39, Walter Bright wrote:

> I made a build of dmd with a collector in it. It destroyed the speed.
> Took it out.

Isn't that bad advertisement for the GC in D? Or has it something to do with DMD not being designed with a GC in mind?

-- 
/Jacob Carlborg

On 23 April 2014 22:24, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> On 23 April 2014 21:55, "Nordlöw" <digitalmars-d@puremagic.com> wrote:
>>> Maybe we should investigate where the memory is going first before planning our attack :-)
>>
>>
>> I agree. Tool anyone?
>
> I'm using valgrind - may take a while to process and merge them all. I'll post an update in the morning.

I was amazed to see some small losses in the glue (that I'll be dealing with), but by and large the worst culprits were all the syntaxCopy'ing done in Template semantic analysis.

The resultant assembly file emitted by gdc is 83MB in size, so I think it is impossible to not have a large memory consumption here.  The stats file is 100MB (39k reported leaks) and I'm not sure just what to do with it yet.

On Wednesday, 23 April 2014 at 08:12:42 UTC, Walter Bright wrote:
> tl;dr: allocation is a critical speed issue with dmd. Using the bump-pointer method is very fast, and it matters.

Alternatively we could replace heap on size threshold.