"Jake The Baker"  wrote in message news:bmwxxjmcoszhbexotufx@forum.dlang.org...

> As far as memory is concerned. How hard would it be to simply have DMD use a swap file? This would fix the out of memory issues and provide some safety(at least you can get your project to compile. Seems like it would be a relatively simple thing to add?

It seems unlikely that having dmd use its own swap file would perform better than the operating system's implementation. 

On Wed, 01 Apr 2015 06:21:58 +0000, deadalnix wrote:

> On Wednesday, 1 April 2015 at 04:51:26 UTC, weaselcat wrote:
>> On Wednesday, 1 April 2015 at 04:49:55 UTC, ketmar wrote:
>>> On Wed, 01 Apr 2015 02:25:43 +0000, Random D-user wrote:
>>>
>>>> GC because of some low-end machines. Memory is really cheap these days and pretty much every machine is 64-bits (even phones are trasitioning fast to 64-bits).
>>>
>>> this is the essense of "modern computing", btw. "hey, we have this resource! hey, we have the only program user will ever want to run, so assume that all that resource is ours! what? just buy a better box!"
>>
>> google/mozilla's developer mantra regarding web browsers.
> 
> They must have an agreement with DRAM vendor, I see no other explanation...

maybe vendors just giving 'em free DRAM chips...

On Monday, 30 March 2015 at 00:12:09 UTC, Walter Bright wrote:
> On 3/29/2015 4:14 PM, Martin Krejcirik wrote:
>> It seems like every DMD release makes compilation slower. This time I see 10.8s
>> vs 7.8s on my little project. I know this is generally least of concern, and
>> D1's lighting-fast times are long gone, but since Walter often claims D's
>> superior compilation speeds, maybe some profiling is in order ?
>
> Sigh. Two things happen constantly:
>
> 1. object file sizes creep up
> 2. compilation speed slows down
>
> It's like rust on your car. Fixing it requires constant vigilance.

Are there any plans to fix this up in a point release? The compile times have really taken a nose dive in v2.067. It's really taken the fun out of the language.

On Monday, 30 March 2015 at 00:12:09 UTC, Walter Bright wrote:
> On 3/29/2015 4:14 PM, Martin Krejcirik wrote:
>> It seems like every DMD release makes compilation slower. This time I see 10.8s
>> vs 7.8s on my little project. I know this is generally least of concern, and
>> D1's lighting-fast times are long gone, but since Walter often claims D's
>> superior compilation speeds, maybe some profiling is in order ?
>
> Sigh. Two things happen constantly:
>
> 1. object file sizes creep up
> 2. compilation speed slows down
>
> It's like rust on your car. Fixing it requires constant vigilance.

I just did some profiling of building phobos. I noticed ~20% of the runtime and ~40% of the L2 cache misses were in slist_reset. Is this expected?

On Wednesday, 1 April 2015 at 02:25:44 UTC, Random D-user wrote:
>> I've used D's GC with DDMD.  It works*, but you're trading better memory usage for worse allocation speed.  It's quite possible we could add a switch to ddmd to enable the GC.
>
> As a random d-user (who cares about perf/speed and just happened to read this) a switch sounds VERY good to me. I don't want to pay the price of GC because of some low-end machines. Memory is really cheap these days and pretty much every machine is 64-bits (even phones are trasitioning fast to 64-bits).
>
> Also, I wanted to add that freeing (at least to the OS (does this apply to GC?)) isn't exactly free either. Infact it can be more costly than mallocing.
> Here's enlightening article: https://randomascii.wordpress.com/2014/12/10/hidden-costs-of-memory-allocation/

I think a switch would be good. My main reason for asking for such a thing isn't for performance (not directly), it's for being able to compile some D programs on computers with less memory. I've had machines with 1 or 2 GB of memory on them, wanted to compile a D program, DMD ran out of memory, and the compiler crashed. You can maybe start swapping on disk, but that won't be too great.

On 04/09/2015 03:41 PM, Gary Willoughby wrote:
> Are there any plans to fix this up in a point release? The compile times have really taken a nose dive in v2.067. It's really taken the fun out of the language.

Filed a bug report, we'll figure something out. https://issues.dlang.org/show_bug.cgi?id=14431

On Friday, 10 April 2015 at 02:02:17 UTC, Martin Nowak wrote:
> On 04/09/2015 03:41 PM, Gary Willoughby wrote:
>> Are there any plans to fix this up in a point release? The compile times
>> have really taken a nose dive in v2.067. It's really taken the fun out
>> of the language.
>
> Filed a bug report, we'll figure something out.
> https://issues.dlang.org/show_bug.cgi?id=14431

Cheers.