On Wednesday, 15 February 2023 at 18:21:34 UTC, Hipreme wrote:
I want to know if there is some way to debug memory leaks in
runtime.
I have been dealing with that by using a profiler and checking
D runtime function calls. Usually those which allocates has
high cpu usage so it can be easy for
On Wednesday, 15 February 2023 at 18:21:34 UTC, Hipreme wrote:
I want to know if there is some way to debug memory leaks in
runtime.
I have been dealing with that by using a profiler and checking
D runtime function calls. Usually those which allocates has
high cpu usage so it can be easy for
I want to know if there is some way to debug memory leaks in
runtime.
I have been dealing with that by using a profiler and checking D
runtime function calls. Usually those which allocates has high
cpu usage so it can be easy for those bigger ones. While for the
smaller ones, this approach
On Wednesday, 23 August 2017 at 20:52:17 UTC, Stefan Koch wrote:
On Wednesday, 23 August 2017 at 17:30:40 UTC, Drake44 wrote:
I'm on a Windows 7 machine and I'm using VisualD as my IDE.
I'm trying to work out what's chewing up all the RAM in a
program I'm writing... is there a tool that I can u
I always use "valgrind --tool=massif" + "massif-visualizer".
Gives me a nice timeline allowing to find quickly who the big
memory consumers (allocation sites) are.
On Wednesday, 23 August 2017 at 17:30:40 UTC, Drake44 wrote:
I'm on a Windows 7 machine and I'm using VisualD as my IDE. I'm
trying to work out what's chewing up all the RAM in a program
I'm writing... is there a tool that I can use that'll show me
what in my program keeps allocating memory?
I'm on a Windows 7 machine and I'm using VisualD as my IDE. I'm
trying to work out what's chewing up all the RAM in a program I'm
writing... is there a tool that I can use that'll show me what in
my program keeps allocating memory?
Thanks
On Sunday, 13 October 2013 at 14:31:13 UTC, Benjamin Thaut wrote:
Am 13.10.2013 16:23, schrieb develop32:
On Sunday, 13 October 2013 at 14:13:39 UTC, Benjamin Thaut
wrote:
Am 13.10.2013 15:52, schrieb develop32:
On Sunday, 13 October 2013 at 13:18:47 UTC, Benjamin Thaut
wrote:
Am 13.10.2013 1
Am 13.10.2013 16:23, schrieb develop32:
On Sunday, 13 October 2013 at 14:13:39 UTC, Benjamin Thaut wrote:
Am 13.10.2013 15:52, schrieb develop32:
On Sunday, 13 October 2013 at 13:18:47 UTC, Benjamin Thaut wrote:
Am 13.10.2013 14:08, schrieb develop32:
Windows task manager shows constantly inc
On Sunday, 13 October 2013 at 14:01:09 UTC, Adam D. Ruppe wrote:
On Sunday, 13 October 2013 at 13:46:13 UTC, develop32 wrote:
My question is, are there any more places in druntime that I
can change so that I will get a notification when allocation
occurs, besides _d_allocmemory?
I set breakpo
On Sunday, 13 October 2013 at 14:13:39 UTC, Benjamin Thaut wrote:
Am 13.10.2013 15:52, schrieb develop32:
On Sunday, 13 October 2013 at 13:18:47 UTC, Benjamin Thaut
wrote:
Am 13.10.2013 14:08, schrieb develop32:
Windows task manager shows constantly increasing memory
usage of my D
application,
Am 13.10.2013 15:52, schrieb develop32:
On Sunday, 13 October 2013 at 13:18:47 UTC, Benjamin Thaut wrote:
Am 13.10.2013 14:08, schrieb develop32:
Windows task manager shows constantly increasing memory usage of my D
application, yet there is ZERO allocation done by it at the time. I have
made a
On Sunday, 13 October 2013 at 13:46:13 UTC, develop32 wrote:
My question is, are there any more places in druntime that I
can change so that I will get a notification when allocation
occurs, besides _d_allocmemory?
I set breakpoints on gc_malloc and gc_qalloc too. I'm pretty sure
they catch m
On Sunday, 13 October 2013 at 13:18:47 UTC, Benjamin Thaut wrote:
Am 13.10.2013 14:08, schrieb develop32:
Windows task manager shows constantly increasing memory usage
of my D
application, yet there is ZERO allocation done by it at the
time. I have
made a hook inside the rt/lifetime.d for _d_al
On Sunday, 13 October 2013 at 13:18:47 UTC, Benjamin Thaut wrote:
Am 13.10.2013 14:08, schrieb develop32:
Windows task manager shows constantly increasing memory usage
of my D
application, yet there is ZERO allocation done by it at the
time. I have
made a hook inside the rt/lifetime.d for _d_al
Am 13.10.2013 14:08, schrieb develop32:
Windows task manager shows constantly increasing memory usage of my D
application, yet there is ZERO allocation done by it at the time. I have
made a hook inside the rt/lifetime.d for _d_allocmemory, and I do get
notified when an array or a class object in
Windows task manager shows constantly increasing memory usage of
my D application, yet there is ZERO allocation done by it at the
time. I have made a hook inside the rt/lifetime.d for
_d_allocmemory, and I do get notified when an array or a class
object in constructed.
What could be the source
On Tuesday, 24 September 2013 at 01:09:29 UTC, growler wrote:
Might be related to or even the same issue reported here:
http://forum.dlang.org/thread/bug-1005...@http.d.puremagic.com/issues/
This is a Valgrind issue though and not DMD related.
It seems I had the same issue, but for Dr Memory
Might be related to or even the same issue reported here:
http://forum.dlang.org/thread/bug-1005...@http.d.puremagic.com/issues/
This is a Valgrind issue though and not DMD related.
On Monday, 23 September 2013 at 21:35:21 UTC, Flamaros wrote:
On Monday, 23 September 2013 at 20:06:20 UTC, Flamaros wrote:
On Saturday, 21 September 2013 at 14:30:19 UTC, Flamaros wrote:
I tried to used Valgrind (Linux) and Dr Memory (Windows)
without success to find a big leak I have in my ap
On Monday, 23 September 2013 at 20:06:20 UTC, Flamaros wrote:
On Saturday, 21 September 2013 at 14:30:19 UTC, Flamaros wrote:
I tried to used Valgrind (Linux) and Dr Memory (Windows)
without success to find a big leak I have in my application.
But both tools can't launch my application without m
On Saturday, 21 September 2013 at 14:30:19 UTC, Flamaros wrote:
I tried to used Valgrind (Linux) and Dr Memory (Windows)
without success to find a big leak I have in my application.
But both tools can't launch my application without make it
crash.
Do I need do something particular, to have a c
On Saturday, 21 September 2013 at 17:03:14 UTC, Brad Roberts
wrote:
On 9/21/13 9:01 AM, Maxim Fomin wrote:
On Saturday, 21 September 2013 at 14:30:19 UTC, Flamaros wrote:
I tried to used Valgrind (Linux) and Dr Memory (Windows)
without success to find a big leak I have
in my application.
But b
On Saturday, 21 September 2013 at 17:03:14 UTC, Brad Roberts
wrote:
That's wrong. Both DMD and Valgrind are software, both of
which can be debugged and changed. Please file appropriate bug
reports, hopefully with nicely minimized test cases.
I ran into an issue like this once where DMD would
On 9/21/13 9:01 AM, Maxim Fomin wrote:
On Saturday, 21 September 2013 at 14:30:19 UTC, Flamaros wrote:
I tried to used Valgrind (Linux) and Dr Memory (Windows) without success to
find a big leak I have
in my application.
But both tools can't launch my application without make it crash.
Is app
On Saturday, 21 September 2013 at 16:01:17 UTC, Maxim Fomin wrote:
On Saturday, 21 September 2013 at 14:30:19 UTC, Flamaros wrote:
I tried to used Valgrind (Linux) and Dr Memory (Windows)
without success to find a big leak I have in my application.
But both tools can't launch my application with
On Saturday, 21 September 2013 at 14:30:19 UTC, Flamaros wrote:
I tried to used Valgrind (Linux) and Dr Memory (Windows)
without success to find a big leak I have in my application.
But both tools can't launch my application without make it
crash.
Is application crashing without these tools? P
I tried to used Valgrind (Linux) and Dr Memory (Windows) without
success to find a big leak I have in my application.
But both tools can't launch my application without make it crash.
Do I need do something particular, to have a chance to see one of
those tool working fine with my application?
On Thursday, 11 April 2013 at 06:55:41 UTC, Ali Çehreli wrote:
On 04/10/2013 10:04 PM, Andrey wrote:> Hello!
> int arr[];
> int length = 100_000_000;
> for (int i=0; i<10; i++)
> {
> arr.length = length; // always new memory blocks,
why?
The slice does not know what
On Thursday, 11 April 2013 at 06:39:53 UTC, Traveler wrote:
On 64 bit may cause crash: arr.length = length, fixed in next
version.
arr.length = 0; // must be deallocation?
Not necessarily. You can manually do a garbage collection.
The manual calling function GC.collect() has no effect (te
On 04/10/2013 10:04 PM, Andrey wrote:> Hello!
> int arr[];
> int length = 100_000_000;
> for (int i=0; i<10; i++)
> {
> arr.length = length; // always new memory blocks, why?
The slice does not know what other slices may be sharing the same
elements. So, increasing
On 64 bit may cause crash: arr.length = length, fixed in next
version.
arr.length = 0; // must be deallocation?
Not necessarily. You can manually do a garbage collection.
Hello!
I'm using Debian 7 system and dmd 2.062.
I use some array functions to test memory allocation process in D
and
have a segmentation fault as a result of this test.
How it works:
1 iteration.
Before allocation we have over 9.5 Mb of virtual memory used.
After allocation we hav
Am 13.03.2013 06:38, schrieb Rob T:
On Tuesday, 12 March 2013 at 21:02:20 UTC, Benjamin Thaut wrote:
This is not possible as different kinds of GCs need to generate
different runtime data at compile time. The current GC for example
does not need any runtime data (other then what the D typeinfo s
On 13.03.2013 08:03, Druzhinin Alexandr wrote:
On 13.03.2013 13:35, Rainer Schuetze wrote:
If the undefined symbols happen to be related to AssociativeArray, my
current workaround is to add "alias Associative!(Key,Value)
_workaround;" somewhere to force instantiation for the respective Key
an
On 13.03.2013 13:35, Rainer Schuetze wrote:
If the undefined symbols happen to be related to AssociativeArray, my
current workaround is to add "alias Associative!(Key,Value)
_workaround;" somewhere to force instantiation for the respective Key
and Value types.
The precise GC needs some type inf
On 13.03.2013 06:46, Druzhinin Alexandr wrote:
On 12.03.2013 20:23, Benjamin Thaut wrote:
Am 12.03.2013 14:07, schrieb bearophile:
Alexandr Druzhinin:
32 bit versions (using dmd and gdc, win7/ubuntu 12.04) of my
application always leak very fast. But 64 bit version (ubuntu 12.04
only, win7
On 12.03.2013 20:23, Benjamin Thaut wrote:
Am 12.03.2013 14:07, schrieb bearophile:
Alexandr Druzhinin:
32 bit versions (using dmd and gdc, win7/ubuntu 12.04) of my
application always leak very fast. But 64 bit version (ubuntu 12.04
only, win7 segfaults) works stable without any leaks. I'm cur
On Tuesday, 12 March 2013 at 21:02:20 UTC, Benjamin Thaut wrote:
This is not possible as different kinds of GCs need to generate
different runtime data at compile time. The current GC for
example does not need any runtime data (other then what the D
typeinfo system already provides) but the per
Benjamin Thaut:
so you can't just "swap" them. You need to recompile.
Is it a good idea to add a compiler switch to specify what GC to
use?
Bye,
bearophile
Am 12.03.2013 21:08, schrieb Rob T:
On Tuesday, 12 March 2013 at 14:21:06 UTC, bearophile wrote:
Benjamin Thaut:
Thats not correct. Rainer Schuetze has finished it and is using it
for VisualD. You can get a version of druntime which the percise GC
from his github branch https://github.com/rain
Am Tue, 12 Mar 2013 21:44:11 +0100
schrieb "Rob T" :
> Do you know if there are instructions posted somewhere on how to
> override or proxy the GC?
>
> --rt
Maybe someone else knows, I just started from here:
https://github.com/D-Programming-Language/druntime/blob/master/src/gcstub/gc.d
When
On Tuesday, 12 March 2013 at 20:29:58 UTC, Marco Leise wrote:
Am Tue, 12 Mar 2013 21:08:01 +0100
schrieb "Rob T" :
It should be a plugin so that components like an alternate GC
can be swapped in and out easily. I hope once shared lib
support becomes available we'll finally see plugins introduc
Am Tue, 12 Mar 2013 21:08:01 +0100
schrieb "Rob T" :
> It should be a plugin so that components like an alternate GC can
> be swapped in and out easily. I hope once shared lib support
> becomes available we'll finally see plugins introduced into dmd.
>
> --rt
Well, you can already today set a
On Tuesday, 12 March 2013 at 14:21:06 UTC, bearophile wrote:
Benjamin Thaut:
Thats not correct. Rainer Schuetze has finished it and is
using it for VisualD. You can get a version of druntime which
the percise GC from his github branch
https://github.com/rainers/dmd
I am glad to be wrong :-)
Am 12.03.2013 15:21, schrieb bearophile:
Benjamin Thaut:
Thats not correct. Rainer Schuetze has finished it and is using it for
VisualD. You can get a version of druntime which the percise GC from
his github branch https://github.com/rainers/dmd
I am glad to be wrong :-)
Do you know how well
On Tuesday, 12 March 2013 at 14:21:06 UTC, bearophile wrote:
Benjamin Thaut:
Thats not correct. Rainer Schuetze has finished it and is
using it for VisualD. You can get a version of druntime which
the percise GC from his github branch
https://github.com/rainers/dmd
I am glad to be wrong :-)
Benjamin Thaut:
Thats not correct. Rainer Schuetze has finished it and is using
it for VisualD. You can get a version of druntime which the
percise GC from his github branch https://github.com/rainers/dmd
I am glad to be wrong :-)
Do you know how well the new GC is working?
Bye,
bearophile
Ah sorry, I meant to post:
https://github.com/rainers/druntime/tree/precise_gc2
Kind Regards
Benjamin Thaut
Am 12.03.2013 14:07, schrieb bearophile:
Alexandr Druzhinin:
32 bit versions (using dmd and gdc, win7/ubuntu 12.04) of my
application always leak very fast. But 64 bit version (ubuntu 12.04
only, win7 segfaults) works stable without any leaks. I'm curious is
there some workaround or I have to w
Alexandr Druzhinin:
32 bit versions (using dmd and gdc, win7/ubuntu 12.04) of my
application always leak very fast. But 64 bit version (ubuntu
12.04 only, win7 segfaults) works stable without any leaks. I'm
curious is there some workaround or I have to wait for GC
improvement to build 32bit v
32 bit versions (using dmd and gdc, win7/ubuntu 12.04) of my application
always leak very fast. But 64 bit version (ubuntu 12.04 only, win7
segfaults) works stable without any leaks. I'm curious is there some
workaround or I have to wait for GC improvement to build 32bit version,
without choice
bearophile wrote:
> You are right, sorry.
No need to apologise! You helped me significantly improve my code,
helped me understand D a lot better and left me feeling generally very
positive about developing further in D. I'd call that a result. :-)
>> So I think it's probably just compiler diffe
> This is the middle parts (the two loops) of Yzlm.objectReputationUpdate
> compiled with ldc, this is one of the two main hot spots of the program, the
> you can compared this asm with the asm of the same part from the C++ version:
To find why the C++ code is faster you can show me the equivale
Joseph Wakeling:
>My guess for the difference is that you ran less than the full 100 iterations
>of the main for loop.<
You are right, sorry.
>So I think it's probably just compiler difference that's to blame for speed
>differences<
This can be true, but such differences are not magic, they
On Wed, 14 Apr 2010 17:19:53 -0400, Joseph Wakeling
wrote:
/
version(Tango) {
import tango.stdc.stdio: printf;
} else {
import std.stdio: printf;
}
void main()
{
double[] x;
for(uint i=0;i<100;++i) {
Hi Bearophile,
Thanks ever so much for the amount of effort you put into this -- it is
extremely kind and generous. :-)
I'm not seeing the significant gains that you see with DMD, but for me
too LDC doubles the speed.
My guess for the difference is that you ran less than the full 100
iterations
57 matches
Mail list logo
