<div dir="ltr">On 28 July 2013 19:29, Chris Angelico <span dir="ltr"><<a href="mailto:rosuav@gmail.com" target="_blank">rosuav@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class=""><div class="h5">On Sun, Jul 28, 2013 at 7:19 PM, Joshua Landau <<a href="mailto:joshua@landau.ws">joshua@landau.ws</a>> wrote:<br>
> On 28 July 2013 09:45, Antoon Pardon <<a href="mailto:antoon.pardon@rece.vub.ac.be">antoon.pardon@rece.vub.ac.be</a>> wrote:<br>
>><br>
>> Op 27-07-13 20:21, <a href="mailto:wxjmfauth@gmail.com">wxjmfauth@gmail.com</a> schreef:<br>
>>><br>
>>> utf-8 or any (utf) never need and never spend their time<br>
>>> in reencoding.<br>
>><br>
>><br>
>> So? That python sometimes needs to do some kind of background<br>
>> processing is not a problem, whether it is garbage collection,<br>
>> allocating more memory, shufling around data blocks or reencoding a<br>
>> string, that doesn't matter. If you've got a real world example where<br>
>> one of those things noticeably slows your program down or makes the<br>
>> program behave faulty then you have something that is worthy of<br>
>> attention.<br>
><br>
><br>
> Somewhat off topic, but befitting of the triviality of this thread, do I<br>
> understand correctly that you are saying garbage collection never causes any<br>
> noticeable slowdown in real-world circumstances? That's not remotely true.<br>
<br>
</div></div>If it's done properly, garbage collection shouldn't hurt the *overall*<br>
performance of the app; most of the issues with GC timing are when one<br>
operation gets unexpectedly delayed for a GC run (making performance<br>
measurement hard, and such). It should certainly never cause your<br>
program to behave faultily, though I have seen cases where the GC run<br>
appears to cause the program to crash - something like this:<br>
<br>
some_string = buggy_call()<br>
...<br>
gc()<br>
...<br>
print(some_string)<br>
<br>
The buggy call mucked up the reference count, so the gc run actually<br>
wiped the string from memory - resulting in a segfault on next usage.<br>
But the GC wasn't at fault, the original call was. (Which, btw, was<br>
quite a debugging search, especially since the function in question<br>
wasn't my code.)<br></blockquote><div><br></div><div>GC does have sometimes severe impact in memory-constrained environments, though. See <a href="http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/">http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/</a>, about half-way down, specifically <a href="http://sealedabstract.com/wp-content/uploads/2013/05/Screen-Shot-2013-05-14-at-10.15.29-PM.png">http://sealedabstract.com/wp-content/uploads/2013/05/Screen-Shot-2013-05-14-at-10.15.29-PM.png</a>.</div>

<div><br></div><div>The best verification of these graphs I could find was <a href="https://blog.mozilla.org/nnethercote/category/garbage-collection/">https://blog.mozilla.org/nnethercote/category/garbage-collection/</a>, although it's not immediately clear in Chrome's and Opera's case mainly due to none of the benchmarks pushing memory usage significantly.</div>

<div><br></div><div>I also don't quite agree with the first post (sealedabstract) because I get by *fine* on 2GB memory, so I don't see why you can't on a phone. Maybe IOS is just really heavy. Nonetheless, the benchmarks aren't lying.</div>

</div></div></div>