Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.albasani.net!newsreader4.netcologne.de!news.netcologne.de!novso.com!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.021 X-Spam-Evidence: '*H*': 0.96; '*S*': 0.00; 'resulting': 0.04; 'debugging': 0.07; 'utf-8': 0.07; 'string': 0.09; 'so?': 0.09; 'url:blog': 0.10; 'cc:addr:python-list': 0.11; 'python': 0.11; '>>': 0.16; '(which,': 0.16; 'behave': 0.16; 'blocks': 0.16; 'buggy': 0.16; 'count,': 0.16; 'garbage': 0.16; 'ios': 0.16; 'lying.': 0.16; 'measurement': 0.16; 'segfault': 0.16; 'thread,': 0.16; 'unexpectedly': 0.16; 'sender:addr:gmail.com': 0.17; 'wrote:': 0.18; '>>>': 0.22; 'appears': 0.22; 'memory': 0.22; 'example': 0.22; 'email addr:gmail.com>': 0.22; 'saying': 0.22; 'cc:addr:python.org': 0.22; '>>>': 0.24; "aren't": 0.24; 'certainly': 0.24; "shouldn't": 0.24; 'string,': 0.24; 'question': 0.24; 'cc:2**0': 0.24; '>': 0.26; 'this:': 0.26; 'post': 0.26; 'gets': 0.27; 'header:In-Reply-To:1': 0.27; 'function': 0.29; 'specifically': 0.29; 'chris': 0.29; "doesn't": 0.30; 'especially': 0.30; 'message-id:@mail.gmail.com': 0.30; 'crash': 0.31; 'delayed': 0.31; 'remotely': 0.31; 'though.': 0.31; 'url:05': 0.31; 'url:category': 0.31; 'run': 0.32; 'quite': 0.32; 'cases': 0.33; 'maybe': 0.34; 'could': 0.34; "can't": 0.35; 'agree': 0.35; 'something': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'really': 0.36; 'done': 0.36; 'next': 0.36; 'url:org': 0.36; 'should': 0.36; 'clear': 0.37; 'performance': 0.37; 'sometimes': 0.38; 'pm,': 0.38; 'does': 0.39; 'most': 0.60; 'impact': 0.61; 'first': 0.61; "you've": 0.63; 'email addr:gmail.com': 0.63; 'kind': 0.63; 'real': 0.63; 'july': 0.63; 'more': 0.64; 'to:addr:gmail.com': 0.65; 'world': 0.66; 'due': 0.66; 'url:png': 0.68; 'attention.': 0.68; 'real-world': 0.68; 'jul': 0.74; 'search,': 0.74; 'topic,': 0.81; 'verification': 0.83; '2gb': 0.84; 'pardon': 0.84; 'url:2013': 0.84; 'usage.': 0.84; 'severe': 0.91; 'url:mozilla': 0.91; 'url :wp-content': 0.91; '2013': 0.98 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=z3Ard5WKLIbCzTYPRyft+/pxajkvaJGasT+yLFgLZYQ=; b=x4dJO6X7XG370noP+tu9ahCmnB2Ax9/XOGKY4K63OdveLLDo0B8urs4J4MQpwKMEOA SEb/KPro1ToeXuHq12skFxC3bNl+ndjVCW/xDmZctMYoF4rlwRBu9bTAvL+BQLWMY+oq OQt2IrMNioKerx/HGnOnzaTwiUJIiX3lP+yQyxeoJIr0HSGyzn4PUZN34Xt8fWEDMGt9 9TWtoG5O+qbv2ltgWgoO2ZrAEBnbK/DDnAkR5Hi+3kkKxUGa+1guX/VNX0D2vkH3wt5i O8u5NrHd1u4FYwJhggrgZV8qDhKdEHhNQfs3Oql+PzPF3lSc4yF1zCBPvjHbVmw8lt96 rYrA== X-Received: by 10.112.5.199 with SMTP id u7mr24700726lbu.67.1375049733183; Sun, 28 Jul 2013 15:15:33 -0700 (PDT) MIME-Version: 1.0 Sender: joshua.landau.ws@gmail.com In-Reply-To: References: <571a6dfe-fd66-42cf-92fc-8b97cbe6e9e4@googlegroups.com> <51DFDE65.5040001@Gmail.com> <4f1067f6-bc99-42ad-9166-37fb228b90e8@googlegroups.com> <51f14395$0$29971$c3e8da3$5496439d@news.astraweb.com> <51f15e03$0$29971$c3e8da3$5496439d@news.astraweb.com> <8203e802-9dc5-44c5-9547-6e1947ee224b@googlegroups.com> <51F4DA25.3030304@rece.vub.ac.be> From: Joshua Landau Date: Sun, 28 Jul 2013 23:14:53 +0100 X-Google-Sender-Auth: ht3bc6oLnsf-50n38_BhJOh1f8w Subject: Re: RE Module Performance To: Chris Angelico Content-Type: multipart/alternative; boundary=14dae94ed6fde51eb404e299b6d7 Cc: python-list X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 151 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1375049741 news.xs4all.nl 16001 [2001:888:2000:d::a6]:33825 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:51410 --14dae94ed6fde51eb404e299b6d7 Content-Type: text/plain; charset=UTF-8 On 28 July 2013 19:29, Chris Angelico wrote: > On Sun, Jul 28, 2013 at 7:19 PM, Joshua Landau wrote: > > On 28 July 2013 09:45, Antoon Pardon > wrote: > >> > >> Op 27-07-13 20:21, wxjmfauth@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.) > GC does have sometimes severe impact in memory-constrained environments, though. See http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/, about half-way down, specifically http://sealedabstract.com/wp-content/uploads/2013/05/Screen-Shot-2013-05-14-at-10.15.29-PM.png . The best verification of these graphs I could find was https://blog.mozilla.org/nnethercote/category/garbage-collection/, although it's not immediately clear in Chrome's and Opera's case mainly due to none of the benchmarks pushing memory usage significantly. 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. --14dae94ed6fde51eb404e299b6d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 28 July 2013 19:29, Chris Angelico &l= t;rosuav@gmail.com> wrote:
On Sun, Jul 28, 2013 at 7:19 PM, Joshua L= andau <joshua@landau.ws> wrot= e:
> On 28 July 2013 09:45, Antoon Pardon <antoon.pardon@rece.vub.ac.be> wrote:
>>
>> Op 27-07-13 20:21, wxjmfaut= h@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 ex= ample where
>> one of those things noticeably slows your program down or makes th= e
>> 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 caus= es any
> noticeable slowdown in real-world circumstances? That's not remote= ly true.

If it's done properly, garbage collection shouldn't hur= t 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 =3D 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.)

GC does have somet= imes severe impact in memory-constrained environments, though. See=C2=A0http= ://sealedabstract.com/rants/why-mobile-web-apps-are-slow/, about half-w= ay down, specifically=C2=A0http://sealedabs= tract.com/wp-content/uploads/2013/05/Screen-Shot-2013-05-14-at-10.15.29-PM.= png.


I also don't quite agree with the first post (seale= dabstract) because I get by *fine* on 2GB memory, so I don't see why yo= u can't on a phone. Maybe IOS is just really heavy. Nonetheless, the be= nchmarks aren't lying.
--14dae94ed6fde51eb404e299b6d7--