RE Module Performance

[Chris Angelico]

On Sun, Jul 28, 2013 at 7:19 PM, Joshua Landau <joshua at landau.ws> wrote:
> On 28 July 2013 09:45, Antoon Pardon <antoon.pardon at rece.vub.ac.be> wrote:
>>
>> Op 27-07-13 20:21, wxjmfauth at gmail.com schreef:
>>>
>>> utf-8 or any (utf) never need and never spend their time
>>> in reencoding.
>>
>>
>> So? That python sometimes needs to do some kind of background
>> processing is not a problem, whether it is garbage collection,
>> allocating more memory, shufling around data blocks or reencoding a
>> string, that doesn't matter. If you've got a real world example where
>> one of those things noticeably slows your program down or makes the
>> program behave faulty then you have something that is worthy of
>> attention.
>
>
> Somewhat off topic, but befitting of the triviality of this thread, do I
> understand correctly that you are saying garbage collection never causes any
> noticeable slowdown in real-world circumstances? That's not remotely true.

If it's done properly, garbage collection shouldn't hurt the *overall*
performance of the app; most of the issues with GC timing are when one
operation gets unexpectedly delayed for a GC run (making performance
measurement hard, and such). It should certainly never cause your
program to behave faultily, though I have seen cases where the GC run
appears to cause the program to crash - something like this:

some_string = buggy_call()
...
gc()
...
print(some_string)

The buggy call mucked up the reference count, so the gc run actually
wiped the string from memory - resulting in a segfault on next usage.
But the GC wasn't at fault, the original call was. (Which, btw, was
quite a debugging search, especially since the function in question
wasn't my code.)

ChrisA