Re: [Python-Dev] cpython (3.2): bounds check for bad data (thanks amaury)

2012-10-27 Thread Serhiy Storchaka
On 27.10.12 03:05, philip.jenvey wrote: > http://hg.python.org/cpython/rev/74d65c746f63 > changeset: 79953:74d65c746f63 > branch: 3.2 > parent: 79941:eb999002916c > user:Philip Jenvey > date:Fri Oct 26 17:01:53 2012 -0700 > summary: >bounds check for bad data (thank

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-10-27 Thread Armin Rigo
Hi Brett, On Fri, Oct 26, 2012 at 9:14 PM, Brett Cannon wrote: > Worst benchmark is nosite_startup, best is telco. May I express doubts about telco? :-) It looks like the Python 3 version is simply not running: > ### telco ### > Min: 0.81 -> 0.01: 81.00x faster > Avg: 0.823600 -> 0.015

Re: [Python-Dev] cpython (3.2): bounds check for bad data (thanks amaury)

2012-10-27 Thread Serhiy Storchaka
Oh, and there is yet one bug. "&&" should be used in the condition instead of "||". Patch attached. diff -r 8e67d5dc069d Python/codecs.c --- a/Python/codecs.c Fri Oct 26 17:05:55 2012 -0700 +++ b/Python/codecs.c Sat Oct 27 12:41:45 2012 +0300 @@ -791,10 +791,10 @@ /* Try decoding a singl

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-10-27 Thread Antoine Pitrou
On Fri, 26 Oct 2012 15:14:08 -0400 Brett Cannon wrote: > > Worst benchmark is nosite_startup, best is telco. The benchmarks people > might want to analyze (i.e. more than 20% slower in Python 3.3) are > mako_v2, threaded_count, normal_startup, iterative_count, pathlib, > formatted_logging, and si

Re: [Python-Dev] cpython (3.2): bounds check for bad data (thanks amaury)

2012-10-27 Thread Serhiy Storchaka
It's too large for Python-Dev quick remark. I open an issue in a bugtracker: http://bugs.python.org/issue16336. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/ma

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-10-27 Thread Maciej Fijalkowski
On Sat, Oct 27, 2012 at 11:35 AM, Armin Rigo wrote: > Hi Brett, > > On Fri, Oct 26, 2012 at 9:14 PM, Brett Cannon wrote: >> Worst benchmark is nosite_startup, best is telco. > > May I express doubts about telco? :-) It looks like the Python 3 > version is simply not running: > >> ### telco ### >

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-10-27 Thread Stefan Krah
Maciej Fijalkowski wrote: > On Sat, Oct 27, 2012 at 11:35 AM, Armin Rigo wrote: > > May I express doubts about telco? :-) It looks like the Python 3 > > version is simply not running: > > > >> ### telco ### > >> Min: 0.81 -> 0.01: 81.00x faster > >> Avg: 0.823600 -> 0.015200: 54.18x fast

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-10-27 Thread Brett Cannon
I did check that markup safe as not installed. It might just be mako doing something silly. The threads tests are very synthetic. And yes, there are more modules at startup. When was the last to,e we looked at them to make sure we weren't doing needless I ports? On Oct 27, 2012 5:56 AM, "Antoine

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-10-27 Thread Nick Coghlan
On Sat, Oct 27, 2012 at 11:20 PM, Brett Cannon wrote: > I did check that markup safe as not installed. It might just be mako doing > something silly. > > The threads tests are very synthetic. > > And yes, there are more modules at startup. When was the last to,e we looked > at them to make sure we

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-10-27 Thread Antoine Pitrou
On Sat, 27 Oct 2012 09:20:36 -0400 Brett Cannon wrote: > I did check that markup safe as not installed. It might just be mako doing > something silly. > > The threads tests are very synthetic. > > And yes, there are more modules at startup. When was the last to,e we > looked at them to make sure

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-10-27 Thread Mark Shannon
On 27/10/12 20:21, Antoine Pitrou wrote: On Sat, 27 Oct 2012 09:20:36 -0400 Brett Cannon wrote: I did check that markup safe as not installed. It might just be mako doing something silly. The threads tests are very synthetic. And yes, there are more modules at startup. When was the last to,e

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-10-27 Thread Tim Delaney
On 28 October 2012 07:40, Mark Shannon wrote: > > I suspect that stating and loading the .pyc files is responsible for most > of the overhead. > PyRun starts up quite a lot faster thanks to embedding all the modules in > the executable: > http://www.egenix.com/**products/python/PyRun/

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-10-27 Thread martin
Zitat von Tim Delaney : To be clear - I'm *not* suggesting Cython become part of the required build toolchain. But *if* the Cython-compiled extensions prove to be significantly faster I'm thinking maybe it could become a semi-supported option (e.g. a HOWTO with the caveat "it worked on this par

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-10-27 Thread Antoine Pitrou
On Sat, 27 Oct 2012 21:40:26 +0100 Mark Shannon wrote: > On 27/10/12 20:21, Antoine Pitrou wrote: > > > > It would be interesting to know *where* the module import time gets > > spent, on a lower level. My gut feeling is that execution of Python > > module code is the main contributor. > > I susp

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-10-27 Thread Paul Moore
On 27 October 2012 21:58, wrote: > > Zitat von Tim Delaney : > > >> To be clear - I'm *not* suggesting Cython become part of the required >> build >> toolchain. But *if* the Cython-compiled extensions prove to be >> significantly faster I'm thinking maybe it could become a semi-supported >> optio

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-10-27 Thread Mark Shannon
On 27/10/12 21:59, Antoine Pitrou wrote: On Sat, 27 Oct 2012 21:40:26 +0100 Mark Shannon wrote: On 27/10/12 20:21, Antoine Pitrou wrote: It would be interesting to know *where* the module import time gets spent, on a lower level. My gut feeling is that execution of Python module code is the m

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-10-27 Thread Antoine Pitrou
On Sat, 27 Oct 2012 22:11:01 +0100 Mark Shannon wrote: > On 27/10/12 21:59, Antoine Pitrou wrote: > > On Sat, 27 Oct 2012 21:40:26 +0100 > > Mark Shannon wrote: > >> On 27/10/12 20:21, Antoine Pitrou wrote: > >>> > >>> It would be interesting to know *where* the module import time gets > >>> spen

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-10-27 Thread Brett Cannon
On Sat, Oct 27, 2012 at 4:40 PM, Mark Shannon wrote: > On 27/10/12 20:21, Antoine Pitrou wrote: > >> On Sat, 27 Oct 2012 09:20:36 -0400 >> Brett Cannon wrote: >> >>> I did check that markup safe as not installed. It might just be mako >>> doing >>> something silly. >>> >>> The threads tests are

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-10-27 Thread Brett Cannon
On Sat, Oct 27, 2012 at 5:07 PM, Paul Moore wrote: > On 27 October 2012 21:58, wrote: > > > > Zitat von Tim Delaney : > > > > > >> To be clear - I'm *not* suggesting Cython become part of the required > >> build > >> toolchain. But *if* the Cython-compiled extensions prove to be > >> significan

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-10-27 Thread Serhiy Storchaka
On 28.10.12 00:07, Paul Moore wrote: Looks like the normal configuration is over twice as fast as the zipped one... The normal configuration does 269 stats, but the zipped one does 12636 seeks. ___ Python-Dev mailing list Python-Dev@python.org http

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-10-27 Thread Serhiy Storchaka
On 28.10.12 01:06, Brett Cannon wrote: I really doubt that as the amount of stat calls is significantly reduced in Python 3.3 compared to Python 3.2 (startup benchmarks show Python 3.3 is roughly 1.66x faster than 3.2 thanks to caching filenames in a directory). $ strace ./python -c '' 2>&1 | g

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-10-27 Thread Antoine Pitrou
On Sun, 28 Oct 2012 01:39:42 +0300 Serhiy Storchaka wrote: > On 28.10.12 01:06, Brett Cannon wrote: > > I really doubt that as the amount of stat calls is significantly reduced > > in Python 3.3 compared to Python 3.2 (startup benchmarks show Python 3.3 > > is roughly 1.66x faster than 3.2 thanks

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-10-27 Thread Gregory P. Smith
One word: profile. Looking at stat counts alone rather than measuring the total time spent in all types of system calls from strace and profiling is not really useful. ;) Another thing to keep an eye out for within a startup profile: how often does the gc collect? our default gc collection thre