Kristján Valur Jónsson kristjan at 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
Hello there.
Consider this code:
def factorial(n):
def helper(n):
if n:
return n*helper(n-1)
else:
return 1
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,
-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? Python has a gc exactly to deal
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
2009/12/8 Maciej Fijalkowski 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, you can have arbitrarily many frees being called before
anything else can
@python.org
Subject: Re: [Python-Dev] recursive closures - reference leak
2009/12/8 Maciej Fijalkowski fij...@gmail.commailto: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
