Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder3.xlned.com!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!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.018 X-Spam-Evidence: '*H*': 0.96; '*S*': 0.00; 'fixes': 0.07; 'calls.': 0.09; 'lines.': 0.09; 'subject:skip:c 10': 0.09; 'cc:addr:python- list': 0.11; 'contribute': 0.11; 'mostly': 0.14; 'defaultdict': 0.16; 'dump': 0.16; 'measurement': 0.16; 'optimised': 0.16; 'roy': 0.16; 'subject:slow': 0.16; 'exception': 0.16; 'sender:addr:gmail.com': 0.17; 'wrote:': 0.18; 'seems': 0.21; 'input': 0.22; 'email addr:gmail.com>': 0.22; 'tests': 0.22; 'cc:addr:python.org': 0.22; 'affects': 0.24; "shouldn't": 0.24; "haven't": 0.24; 'cc:2**0': 0.24; 'right.': 0.26; 'header:In- Reply-To:1': 0.27; 'point': 0.28; 'function': 0.29; 'patch': 0.29; 'message-id:@mail.gmail.com': 0.30; 'lines': 0.31; 'file': 0.32; 'extend': 0.32; 'totally': 0.33; 'agree': 0.35; 'case,': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'opposed': 0.36; 'surely': 0.36; 'doing': 0.36; 'should': 0.36; 'skip:& 10': 0.38; '8bit%:86': 0.38; "couldn't": 0.39; 'free': 0.61; 'full': 0.61; 'real': 0.63; 'july': 0.63; 'more': 0.64; 'different': 0.65; 'to:addr:gmail.com': 0.65; 'world': 0.66; 'smith': 0.68; 'containing': 0.69; 'repeat': 0.74; 'other.': 0.75; 'approach.': 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=lwFrChsK2uTBwc/GWdTbPYxVFqVnC4WMsBp+Wo5e7N4=; b=LBnw489AgQl3EoTRXSeaF5bAUWz761jVzIvr1Flqpn3dj7fhL+gbjZTx0mK+Y+t4mv YLO4ueMRQHyoROSKyoYZuWb26Xc5ILJ4GSgwBTZzh58zz8t3pjzXbPZMOkdVehczSnxf j27NUTpRUmW7SuU7pwzjRY7vwBG0jM3QzEToUKsjxY35MwUZNNmvGFHjnQxOViSKMgJc LerK5FpgFsk+vJ4Flkr4enUVfc2seSwdeLBMNFXoLO9hz9U3paxUfp3L1aHd1VJ/cwP3 THcyUNMpuAAwIqHF9lqZ3EuiL1h1iXuHuWa5ocYyn6GbHBJzT2zqKvo0JOaOEv3V0nnW xAcQ== X-Received: by 10.152.42.193 with SMTP id q1mr8650156lal.65.1375098633461; Mon, 29 Jul 2013 04:50:33 -0700 (PDT) MIME-Version: 1.0 Sender: joshua.landau.ws@gmail.com In-Reply-To: References: From: Joshua Landau Date: Mon, 29 Jul 2013 12:49:53 +0100 X-Google-Sender-Auth: WTOunxAlnlX1FETaL9x9h4yjvFU Subject: Re: collections.Counter surprisingly slow To: Serhiy Storchaka Content-Type: multipart/alternative; boundary=001a11c3643894271f04e2a51987 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: 109 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1375098641 news.xs4all.nl 15984 [2001:888:2000:d::a6]:57278 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:51436 --001a11c3643894271f04e2a51987 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29 July 2013 07:25, Serhiy Storchaka wrote: > 28.07.13 22:59, Roy Smith =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2(=D0= =BB=D0=B0): > > The input is an 8.8 Mbyte file containing about 570,000 lines (11,000 >> unique strings). >> > > Repeat you tests with totally unique lines. Counter is about =C2=BD the speed of defaultdict in that case (as opposed t= o =E2=85=93). > The full profiler dump is at the end of this message, but the gist of >> it is: >> > > Profiler affects execution time. In particular it slowdown Counter > implementation which uses more function calls. For real world measurement > use different approach. Doing some re-times, it seems that his originals for defaultdict, exception and Counter were about right. I haven't timed the other. > Why is count() [i.e. collections.Counter] so slow? >> > > Feel free to contribute a patch which fixes this "wart". Note that Counte= r > shouldn't be slowdowned on mostly unique data. I find it hard to agree that counter should be optimised for the unique-data case, as surely it's much more oft used when there's a point to counting? Also, couldn't Counter just extend from defaultdict? --001a11c3643894271f04e2a51987 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 29 July 2013 07:25, Serhiy Storchaka = <storchaka@gmai= l.com> wrote:
28.07.13 22:59, Roy Smith =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0=D0=B2(=D0=BB=D0=B0):

=C2=A0 The input is an 8.8 Mbyte file containing about 570,000 lines (11,00= 0
unique strings).

Repeat you tests with totally unique lines.

Counter is about =C2=BD the speed of defaultdict in that case (as opposed = to=C2=A0=E2=85=93).
=C2=A0
The full profiler dump is at the end of this message, but the gist of
it is:

Profiler affects execution time. In particular it slowdown Counter implemen= tation which uses more function calls. For real world measurement use diffe= rent approach.

Doing some re-times, it seem= s that his originals for defaultdict, exception and Counter were about righ= t. I haven't timed the other.
=C2=A0
Why is count() [i.e. collections.Counter] so slow?

Feel free to contribute a patch which fixes this "wart". Note tha= t Counter shouldn't be slowdowned on mostly unique data.

I find it hard to agree that counter should be optimised = for the unique-data case, as surely it's much more oft used when there&= #39;s a point to counting?

Also, couldn't Counter just extend from defaultdict= ?
--001a11c3643894271f04e2a51987--