On 11/24/19 10:34 AM, Jacob Carlborg wrote:
On 2019-11-18 01:20, Steven Schveighoffer wrote:
I'm fighting some out of memory problems using DMD and some
super-template heavy code.
I have ideas on how to improve the situation, but it involves
redesigning a large portion of the design. I want t
On 2019-11-18 01:20, Steven Schveighoffer wrote:
I'm fighting some out of memory problems using DMD and some
super-template heavy code.
I have ideas on how to improve the situation, but it involves
redesigning a large portion of the design. I want to do it
incrementally, but I need to see thi
On Monday, 18 November 2019 at 00:20:12 UTC, Steven Schveighoffer
wrote:
I'm fighting some out of memory problems using DMD and some
super-template heavy code.
I have ideas on how to improve the situation, but it involves
redesigning a large portion of the design. I want to do it
incrementall
On Monday, 18 November 2019 at 00:20:12 UTC, Steven Schveighoffer
wrote:
I'm fighting some out of memory problems using DMD and some
super-template heavy code.
I have ideas on how to improve the situation, but it involves
redesigning a large portion of the design. I want to do it
incrementall
On 11/18/19 11:15 AM, Steven Schveighoffer wrote:
On 11/18/19 10:36 AM, Jacob Carlborg wrote:
On Monday, 18 November 2019 at 15:31:02 UTC, Steven Schveighoffer wrote:
I don't think this will work for me, as this isn't CTFE, and I'm
assuming the instantiated templates won't be collected because
On 11/18/19 10:36 AM, Jacob Carlborg wrote:
On Monday, 18 November 2019 at 15:31:02 UTC, Steven Schveighoffer wrote:
I don't think this will work for me, as this isn't CTFE, and I'm
assuming the instantiated templates won't be collected because they
stay referenced for the whole program.
You
On Monday, 18 November 2019 at 15:31:02 UTC, Steven Schveighoffer
wrote:
I don't think this will work for me, as this isn't CTFE, and
I'm assuming the instantiated templates won't be collected
because they stay referenced for the whole program.
You could also combine that flag with the GC prof
On 11/18/19 3:16 AM, Jacob Carlborg wrote:
On Monday, 18 November 2019 at 00:20:12 UTC, Steven Schveighoffer wrote:
I'm fighting some out of memory problems using DMD and some
super-template heavy code.
Try to enable the GC using the `-lowmem` flag [1].
[1] https://dlang.org/changelog/2.086.0
On 11/17/19 7:48 PM, ikod wrote:
On Monday, 18 November 2019 at 00:20:12 UTC, Steven Schveighoffer wrote:
I'm fighting some out of memory problems using DMD and some
super-template heavy code.
I have ideas on how to improve the situation, but it involves
redesigning a large portion of the des
On 11/17/19 7:33 PM, Adam D. Ruppe wrote:
On Monday, 18 November 2019 at 00:20:12 UTC, Steven Schveighoffer wrote:
Is there a straightforward way to figure out how much memory the
compiler uses during compilation?
So this isn't a great solution but what I have done in the past is just
have a
On Monday, 18 November 2019 at 00:20:12 UTC, Steven Schveighoffer
wrote:
I'm fighting some out of memory problems using DMD and some
super-template heavy code.
Try to enable the GC using the `-lowmem` flag [1].
[1] https://dlang.org/changelog/2.086.0.html#lowmem
—
/Jacob Carlborg
On Monday, 18 November 2019 at 00:20:12 UTC, Steven Schveighoffer
wrote:
I'm fighting some out of memory problems using DMD and some
super-template heavy code.
I have ideas on how to improve the situation, but it involves
redesigning a large portion of the design. I want to do it
incrementall
On Monday, 18 November 2019 at 00:20:12 UTC, Steven Schveighoffer
wrote:
Is there a straightforward way to figure out how much memory
the compiler uses during compilation?
So this isn't a great solution but what I have done in the past
is just have a little script running
ps aux | grep dmd
s
I'm fighting some out of memory problems using DMD and some
super-template heavy code.
I have ideas on how to improve the situation, but it involves
redesigning a large portion of the design. I want to do it
incrementally, but I need to see things improving.
Is there a straightforward way to
On Thu, Aug 29, 2013 at 01:46:03AM +0200, Marek Janukowicz wrote:
> H. S. Teoh wrote:
>
> > On Thu, Aug 29, 2013 at 12:45:05AM +0200, Marek Janukowicz wrote:
> >> H. S. Teoh wrote:
> > [...]
> >> > Oh, and BTW, are you on Linux 32-bit or 64-bit? Don't know if
> >> > that makes a difference, but ju
H. S. Teoh wrote:
> On Thu, Aug 29, 2013 at 12:45:05AM +0200, Marek Janukowicz wrote:
>> H. S. Teoh wrote:
> [...]
>> > Oh, and BTW, are you on Linux 32-bit or 64-bit? Don't know if that
>> > makes a difference, but just in case.
>>
>> 64-bit
> [...]
>
> Maybe try compiling with -m32 and see if
On Thu, Aug 29, 2013 at 12:45:05AM +0200, Marek Janukowicz wrote:
> H. S. Teoh wrote:
[...]
> > Oh, and BTW, are you on Linux 32-bit or 64-bit? Don't know if that
> > makes a difference, but just in case.
>
> 64-bit
[...]
Maybe try compiling with -m32 and see if it makes a difference? If so,
it m
H. S. Teoh wrote:
> On Wed, Aug 28, 2013 at 11:02:17PM +0200, Marek Janukowicz wrote:
>> I was finally able to create simple test case that probably reproduces
>> the bug (probably, because the stack trace is completely different,
>> but the code that is there is similar). This requires 2 source c
On Wed, Aug 28, 2013 at 02:10:34PM -0700, H. S. Teoh wrote:
> On Wed, Aug 28, 2013 at 11:02:17PM +0200, Marek Janukowicz wrote:
> > I was finally able to create simple test case that probably
> > reproduces the bug (probably, because the stack trace is completely
> > different, but the code that is
On Wed, Aug 28, 2013 at 11:02:17PM +0200, Marek Janukowicz wrote:
> I was finally able to create simple test case that probably reproduces
> the bug (probably, because the stack trace is completely different,
> but the code that is there is similar). This requires 2 source code
> files:
[...]
> Run
I was finally able to create simple test case that probably reproduces the
bug (probably, because the stack trace is completely different, but the code
that is there is similar). This requires 2 source code files:
main.d:
module main;
// This line must be there - import any module from std cau
rithm, say, update all your imports
accordingly, and then just edit the file and delete the parts you don't
use. For example, if you don't use any of the set functions (merge,
cartesianProduct, etc.), just delete them from the file along with all
their unittests. This should reduce
luded takes almost 4GB of RAM. While I'm aware of the fact DMD
deliberately doesn't free the memory for performance purposes, this makes
the compilation fail due to insufficient memory on machines with 4GB RAM
(and some taken).
So my questions are:
- how can I limit DMD memory usage?
23 matches
Mail list logo
