D.gnu - top 8 entry from grpof of my app :-(
- %u (22/22) Jan 09 2007 compiled with 0.21, mingw: -g -gc -debug -profile
- %u (15/15) Jan 09 2007 same figure demangled.
- Thomas Kuehne (13/35) Jan 09 2007 -----BEGIN PGP SIGNED MESSAGE-----
- %u (6/6) Jan 09 2007 Thanks for the info.
- Oskar Linde (5/12) Jan 10 2007 I'd recommend disabling the GC while building the tree.
- Thomas Kuehne (11/17) Jan 11 2007 -----BEGIN PGP SIGNED MESSAGE-----
- %u (1/3) Jan 11 2007 It shouldn't, the machine has total 2G physical memory.
- janderson (11/20) Jan 13 2007 You should try pre-allocate a pool of memory for the nodes (a big
- %u (3/4) Jan 15 2007 I checked it, it's a C library. How does it work with D? e.g. how to al...
- Lionello Lunesu (6/13) Jan 16 2007 http://www.digitalmars.com/d/memory.html#newdelete
- Frits van Bommel (21/23) Jan 10 2007 Not entirely up-to-date:
- Thomas Kuehne (10/33) Jan 11 2007 -----BEGIN PGP SIGNED MESSAGE-----
compiled with 0.21, mingw: -g -gc -debug -profile From the 9th entry, begins function of my app So total 93.2% time spent in GC? Can anyone give me some suggestions on how to improve? Thanks! ====================================================== Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls s/call s/call name 38.84 657.63 657.63 _D3gcx3Gcx8findPoolMFPvZPS3gcx4Pool 24.43 1071.29 413.66 _D3gcx3Gcx4markMFPvPvZv 9.52 1232.48 161.19 _D3gcx3Gcx11fullcollectMFPvZk 6.71 1346.01 113.53 _D6gcbits6GCBits4testMFkZk 5.87 1445.33 99.32 _D3gcx4Pool10allocPagesMFkZk 3.64 1507.03 61.70 _D9invariant12_d_invariantFC6ObjectZv 3.21 1561.38 54.35 _D6gcbits6GCBits3setMFkZv 0.98 1578.03 16.65 _D3gcx12sentinel_addFPvZPv ======================================================
Jan 09 2007
%u <no where.com> same figure demangled. =========================================================== Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls s/call s/call name 38.84 657.63 657.63 MFPvZPS3gcx4Pool gcx.Gcx.findPool 24.43 1071.29 413.66 MFPvPvZv gcx.Gcx.mark 9.52 1232.48 161.19 MFPvZk gcx.Gcx.fullcollect 6.71 1346.01 113.53 MFkZk gcbits.GCBits.test 5.87 1445.33 99.32 MFkZk gcx.Pool.allocPages 3.64 1507.03 61.70 void invariant._d_invariant(class Object) 3.21 1561.38 54.35 MFkZv gcbits.GCBits.set 0.98 1578.03 16.65 void* gcx.sentinel_add(void*)
Jan 09 2007
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 %u schrieb am 2007-01-10:compiled with 0.21, mingw: -g -gc -debug -profile From the 9th entry, begins function of my app So total 93.2% time spent in GC? Can anyone give me some suggestions on how to improve? Thanks! ====================================================== Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls s/call s/call name 38.84 657.63 657.63 _D3gcx3Gcx8findPoolMFPvZPS3gcx4Pool 24.43 1071.29 413.66 _D3gcx3Gcx4markMFPvPvZv 9.52 1232.48 161.19 _D3gcx3Gcx11fullcollectMFPvZk 6.71 1346.01 113.53 _D6gcbits6GCBits4testMFkZk 5.87 1445.33 99.32 _D3gcx4Pool10allocPagesMFkZk 3.64 1507.03 61.70 _D9invariant12_d_invariantFC6ObjectZv 3.21 1561.38 54.35 _D6gcbits6GCBits3setMFkZv 0.98 1578.03 16.65 _D3gcx12sentinel_addFPvZPv ======================================================Dear %u, could you please roughly describe what your program is supposed to do and the basic algorithm(s) you used to implement it? (You can get an up-to-date demangler commandline demangler via Subversion: svn checkout http://svn.berlios.de/svnroot/repos/ddemangled) Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFFpJmVLK5blCcjpWoRAl2zAJ499ty/b7JnNT3CVsDtvhgdy29R2gCbBm+9 7J0SxShZoJUnQsdJSUl3XL8= =3G/h -----END PGP SIGNATURE-----
Jan 09 2007
Thanks for the info. Sorry, I should mention the program do some game tree searching. It need to allocate some memory for each new node, and then do some calculation. In that test, the total memory allocated is about 500M, and take about 10 min. I should also mention most part of the run it only allocates memory, but doesn't release much until the end when the program exits.
Jan 09 2007
%u wrote:Thanks for the info. Sorry, I should mention the program do some game tree searching. It need to allocate some memory for each new node, and then do some calculation. In that test, the total memory allocated is about 500M, and take about 10 min. I should also mention most part of the run it only allocates memory, but doesn't release much until the end when the program exits.I'd recommend disabling the GC while building the tree. std.gc.disable(); std.gc.enable() when you need it again. /Oskar
Jan 10 2007
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 %u schrieb am 2007-01-10:Thanks for the info. Sorry, I should mention the program do some game tree searching. It need to allocate some memory for each new node, and then do some calculation. In that test, the total memory allocated is about 500M, and take about 10 min. I should also mention most part of the run it only allocates memory, but doesn't release much until the end when the program exits.How much free RAM/swap do you have before starting the application? It looks like the GC thinks it is running out of free memory. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFFpfqZLK5blCcjpWoRAsA3AKCHJiYw+WEmzw18OeoA7rvpE5bAdgCdG5mh +hQ7Xt0O7sFswqIOSV5UwvY= =2GZH -----END PGP SIGNATURE-----
Jan 11 2007
How much free RAM/swap do you have before starting the application? It looks like the GC thinks it is running out of free memory.It shouldn't, the machine has total 2G physical memory.
Jan 11 2007
%u wrote:Thanks for the info. Sorry, I should mention the program do some game tree searching. It need to allocate some memory for each new node, and then do some calculation. In that test, the total memory allocated is about 500M, and take about 10 min. I should also mention most part of the run it only allocates memory, but doesn't release much until the end when the program exits.You should try pre-allocate a pool of memory for the nodes (a big array). That's standard practice with trees. Probably don't even need to disable the GC then. Also if its for a game, you should avoid or remove all allocation during the real-time part of the game (most high performance games (in any language) work this way). Allocation should mostly occur during load times and between levels. You might also try nedmalloc. Good luck, -Joel
Jan 13 2007
Thank you for the suggestions.You might also try nedmalloc.I checked it, it's a C library. How does it work with D? e.g. how to allocate D class (not struct) array? Any experience with it?
Jan 15 2007
%u wrote:Thank you for the suggestions.http://www.digitalmars.com/d/memory.html#newdelete Basically, you just declare the function from the C lib, for example: extern(C) void* nedmalloc(size_t);//just a guess And you can use it. Must still link to the lib though :) L.You might also try nedmalloc.I checked it, it's a C library. How does it work with D? e.g. how to allocate D class (not struct) array? Any experience with it?
Jan 16 2007
Thomas Kuehne wrote:(You can get an up-to-date demangler commandline demangler via Subversion: svn checkout http://svn.berlios.de/svnroot/repos/ddemangled)Not entirely up-to-date: ----- case 'b': /* deprecated since DMD-0.148 (2006-02-25) */ nestpend(dest, "bit", is_nested); source += 1; break; case 'x': nestpend(dest, "bool", is_nested); source += 1; break; ----- should be: ----- case 'b': nestpend(dest, "bool", is_nested); source += 1; break; ----- bool is now mangled as 'b', bit doesn't exist as a basic type anymore. I'm pretty sure 'x' is no longer used.
Jan 10 2007
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Frits van Bommel schrieb am 2007-01-10:Thomas Kuehne wrote:Thanks, fixed Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFFpfukLK5blCcjpWoRAvLGAJkB1PnMklomyxUTIb4FK6Mpe2ZsywCgmwLv O36Yz7eCSXg6eLvOwRH/K+A= =dwdd -----END PGP SIGNATURE-----(You can get an up-to-date commandline demangler via Subversion: svn checkout http://svn.berlios.de/svnroot/repos/ddemangled)Not entirely up-to-date: ----- case 'b': /* deprecated since DMD-0.148 (2006-02-25) */ nestpend(dest, "bit", is_nested); source += 1; break; case 'x': nestpend(dest, "bool", is_nested); source += 1; break; ----- should be: ----- case 'b': nestpend(dest, "bool", is_nested); source += 1; break; ----- bool is now mangled as 'b', bit doesn't exist as a basic type anymore. I'm pretty sure 'x' is no longer used.
Jan 11 2007