Jump to page: 1 2
Thread overview
top 8 entry from grpof of my app :-(
Jan 10, 2007
%u
Jan 10, 2007
%u
Jan 10, 2007
Thomas Kuehne
Jan 10, 2007
%u
Jan 10, 2007
Oskar Linde
Jan 11, 2007
Thomas Kuehne
Jan 11, 2007
%u
Jan 13, 2007
janderson
Jan 15, 2007
%u
Jan 16, 2007
Lionello Lunesu
Jan 10, 2007
Frits van Bommel
Jan 11, 2007
Thomas Kuehne
January 10, 2007
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
======================================================

January 10, 2007
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*)
January 10, 2007
%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


January 10, 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.


January 10, 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
January 10, 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.
January 11, 2007
%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


January 11, 2007
Frits van Bommel schrieb am 2007-01-10:
> Thomas Kuehne wrote:
>> (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.

Thanks, fixed

Thomas


January 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.

January 13, 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
« First   ‹ Prev
1 2