Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed2.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.013 X-Spam-Evidence: '*H*': 0.98; '*S*': 0.00; 'subject:Python': 0.06; 'compiler': 0.07; 'bits': 0.09; 'differing': 0.09; 'imply': 0.09; 'parameter': 0.09; 'python': 0.11; 'changes': 0.15; '0.001': 0.16; '65536': 0.16; 'did.': 0.16; 'key=': 0.16; 'knock': 0.16; 'non- ascii': 0.16; 'regression': 0.16; 'specifying': 0.16; 'windows?': 0.16; 'wrote:': 0.18; 'header:User-Agent:1': 0.23; 'unicode': 0.24; '(or': 0.24; 'subject:/': 0.26; 'header:In-Reply-To:1': 0.27; 'am,': 0.29; 'character': 0.29; '3.2': 0.31; 'keys': 0.31; 'steven': 0.31; 'could': 0.34; "can't": 0.35; 'but': 0.35; "didn't": 0.36; 'version,': 0.38; 'to:addr:python-list': 0.38; 'explain': 0.39; 'to:addr:python.org': 0.39; 'results.': 0.60; 'more': 0.64; 'size.': 0.65; 'between': 0.67; 'received:74.208': 0.68; 'results': 0.69; 'caused': 0.69; 'saw': 0.77; 'experiment': 0.84; 'received:74.208.4.194': 0.84; 'subject:long': 0.84; 'timings': 0.84 Date: Wed, 03 Apr 2013 06:20:37 -0400 From: Dave Angel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: python-list@python.org Subject: Re: Performance of int/long in Python 3 References: <87dff083-14d8-4163-89f3-d78a9be6c802@c15g2000vbl.googlegroups.com> <3qadncD4-6fcPsbMnZ2dnUVZ_rqdnZ2d@westnet.com.au> <515bbedb$0$29891$c3e8da3$5496439d@news.astraweb.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:4YJOmYYGGI0TfScWNbsNqYoQq5SOMasnX0gNag3N1ae f82lwbEt3eG/4F/+nNDSUiVZ2RUIAnQuepsJgW/j47L3pkikj7 Vh442lb9za1TcNpWKPbP1ezYNxO/ivWjVQjLNQznOC87DDKxv5 2oaJvzMI31N3rrK7OnL5zd6gO+NgXZzm6rhsVAd92egEcDLePy XCVcqQq+OZHq6Nvb3aXGXgy3NT2KiJ+R+S9gnY7XoE3he0QGEL TudaCh5yAhFptuxyw6Tv7pYdz/t9Q9Ja3ezWa0wmjShjgvebj6 r5r1AeJnOA0VS1UYuI/DsMjPWOQwWzsBZ8JHqippItJFnDpzQ= = 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: 30 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1364984455 news.xs4all.nl 6988 [2001:888:2000:d::a6]:35862 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:42650 On 04/03/2013 04:22 AM, Neil Hodgson wrote: > rusi: > >> Can you please try one more experiment Neil? >> Knock off all non-ASCII strings (paths) from your dataset and try >> again. > > Results are the same 0.40 (well, 0.001 less but I don't think the > timer is that accurate) for Python 3.2 and 0.78 for Python 3.3. > > Neil That would seem to imply that the speed regression on your data is NOT caused by the differing size encodings. Perhaps it is the difference in MSC compiler version, or other changes made between 3.2 and 3.3 Of course, I can't then explain why Steven didn't get the same results. Perhaps the difference between 32bit Python and 64 on Windows? Or perhaps you have significantly more (or significantly fewer) "collisions" than Steven did. Before I saw this message, I was thinking of suggesting that you supply a key= parameter to sort, specifying as a key the Unicode character 65536 higher than the one supplied. That way all the keys to be sorted would be 32 bits in size. If this made the timings change noticeably, it could be a big clue. -- DaveA