Kristján Valur Jónsson ccpgames.com> writes:
>
> a gc.collect() cycle visits a large amount of objects that it
> won‘t release causing cache thrashing.
>
> There is a reason we disabled ‚gc‘, and it is simply because we
> get lower cpu and smoother execution.
Could you try to enable the gc with
@python.org
Subject: Re: [Python-Dev] recursive closures - reference leak
2009/12/8 Maciej Fijalkowski mailto:fij...@gmail.com>>
Note that disabling gc
does not mean that you will not have unpredictable pauses. Consider
for example that if you loose a reference to a very long chain of
objects, y
2009/12/8 Maciej Fijalkowski
> Note that disabling gc
> does not mean that you will not have unpredictable pauses. Consider
> for example that if you loose a reference to a very long chain of
> objects, you can have arbitrarily many frees being called before
> anything else can happen.
>
That st
>
> Ah, yes. In my particular case, I'm running a cluster of hundreds of nodes,
> supporting 50.000 players in a real-time space simulation. We disable GC
> because of its unpredictable performance impact and are careful to avoid
> reference cycles. We use gc from time to time to _find_ those
> -Original Message-
> From: Hrvoje Niksic [mailto:hrvoje.nik...@avl.com]
> Sent: 8. desember 2009 13:52
> To: Kristján Valur Jónsson
> Cc: python-dev@python.org
> Subject: Re: [Python-Dev] recursive closures - reference leak
> What problem are you referring to? Py
Kristján Valur Jónsson wrote:
The problem with this is that once you have called factorial() once, you
end up with a recursive cycle. „factorial“ has become a cell object,
referencing the „helper“ function, which again refers to the outer cell
object. This requires „gc“ to clean up. Also, it
Hello there.
Consider this code:
def factorial(n):
def helper(n):
if n:
return n*helper(n-1)
else:
return 1
r
