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

[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 (thanks amaury)

> +if (strlen(p) > 2 &&


First, it produces compiler warning:

Python/codecs.c: In function ‘PyCodec_SurrogatePassErrors’:
Python/codecs.c:794: warning: pointer targets in passing argument 1 of ‘strlen’ 
differ in signedness
/usr/include/string.h:397: note: expected ‘const char *’ but argument is of 
type ‘unsigned char *’

Second, it slowdown the code to 10%:

$ ./python-orig -m timeit -s 'b=b"\xed\xa0\xa0"+b"x"*1'  'b.decode("utf-8", 
"surrogatepass")'
10 loops, best of 3: 12.2 usec per loop
$ ./python -m timeit -s 'b=b"\xed\xa0\xa0"+b"x"*1'  'b.decode("utf-8", 
"surrogatepass")'
10 loops, best of 3: 13.3 usec per loop


I suggest to use the followed code instead:

 if (PyBytes_GET_SIZE(object) - start >= 3 &&


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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.015200: 54.18x faster


A bientôt,

Armin.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 single surrogate character. If
there are more, let the codec call us again. */
 p += start;
-if (strlen(p) > 2 &&
-((p[0] & 0xf0) == 0xe0 ||
- (p[1] & 0xc0) == 0x80 ||
- (p[2] & 0xc0) == 0x80)) {
+if (PyBytes_GET_SIZE(object) - start >= 3 &&
+(p[0] & 0xf0) == 0xe0 &&
+(p[1] & 0xc0) == 0x80 &&
+(p[2] & 0xc0) == 0x80) {
 /* it's a three-byte code */
 ch = ((p[0] & 0x0f) << 12) + ((p[1] & 0x3f) << 6) + (p[2] & 0x3f);
 if (ch < 0xd800 || ch > 0xdfff)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 simple_logging.

Well, did you check that mako_v2 wasn't subject to the Markupsafe
issue?

threaded_count and iterative_count are completely dumb.
Slower startup is due to the fact that Python 3 needs many more
modules to even start itself.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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/mailman/options/python-dev/archive%40mail-archive.com

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

[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 ###
>> Min: 0.81 -> 0.01: 81.00x faster
>> Avg: 0.823600 -> 0.015200: 54.18x faster
>
>
> A bientôt,
>
> Armin.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com

I think the original explanation was cDecimal vs decimal.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 faster
> 
> I think the original explanation was cDecimal vs decimal.

Yes, the magnitude of the speedup looks correct. In an isolated benchmark
with the large input file [1] I'm getting 30x speedup for telco.


Stefan Krah

[1] http://www.bytereef.org/mpdecimal/quickstart.html#telco-benchmark - 
expon180-1e6b.zip


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 Pitrou"  wrote:

> 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 simple_logging.
>
> Well, did you check that mako_v2 wasn't subject to the Markupsafe
> issue?
>
> threaded_count and iterative_count are completely dumb.
> Slower startup is due to the fact that Python 3 needs many more
> modules to even start itself.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 weren't doing needless I ports?

It's been quite a while.

>>> py3k - py27
set(['reprlib', 'heapq', '_collections', 'functools', '_bisect',
'copyreg', 'io', 'operator', '_heapq', '_io', '_thread',
'encodings.latin_1', 'collections', '_frozen_importlib',
'collections.abc', 'builtins', '_sysconfigdata', '_functools',
'keyword', '_imp', 'bisect', 'weakref', 'itertools', 'marshal'])

>>> py27 - py3k
set(['exceptions', 'copy_reg', 'warnings', 'UserDict', 'traceback',
'encodings.codecs', '__builtin__', 'linecache', '_abcoll',
'encodings.__builtin__', 'encodings.encodings', 'types'])

To check how many of those dependencies stemmed from collections, I
checked against the 2.7 version:

>>> py3k - py27_with_collections
set(['_functools', 'reprlib', '_thread', '_io', '_imp',
'_frozen_importlib', 'functools', 'weakref', 'collections.abc',
'encodings.latin_1', 'io', 'copyreg', 'builtins', 'marshal',
'_sysconfigdata'])

>>> py27_with_collections - py3k
set(['exceptions', 'copy_reg', 'thread', 'warnings', 'UserDict',
'traceback', 'encodings.codecs', '__builtin__', 'linecache',
'_abcoll', 'encodings.__builtin__', 'encodings.encodings', 'types'])

Implicitly bringing in _thread is a bit of a worry. Apparently 3.2 had
the same problem, though:

>>> py3k - py32
{'_imp', '_frozen_importlib', '_warnings', 'collections.abc',
'marshal', '_sysconfigdata'}

>>> py32 - py3k
{'_locale', 'locale', 'traceback', 'linecache', 'token', '_abcoll', 'tokenize'}


Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 we weren't doing needless I ports?

The last time was between 3.2 and 3.3. It will be hard to lower the
number of imported modules, given the current semantics (io, importlib,
unicode, site.py, sysconfig...). Python 2's view of the world was much
simpler (naïve?) in comparison.

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.

Regards

Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 we
looked at them to make sure we weren't doing needless I ports?


The last time was between 3.2 and 3.3. It will be hard to lower the
number of imported modules, given the current semantics (io, importlib,
unicode, site.py, sysconfig...). Python 2's view of the world was much
simpler (naïve?) in comparison.

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 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/


Freezing all the core modules into the executable should reduce start up 
time.


Cheers,
Mark

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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/
>
> Freezing all the core modules into the executable should reduce start up
> time.
>

That suggests a test to me that the Cython guys might be interested in (or
may well have performed in the past). How much of the stdlib could be
compiled with Cython and used during the startup process? How much of an
effect would it have on startup times and these benchmarks if
Cython-compiled extensions were used?

I'm thinking here of elimination of .pyc interpretation and execution (stat
calls would be similar, probably slightly higher).

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 particular system").

Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 particular system").


This should compare to zipping the standard library, which has been a  
supported

configuration for a long time, and also avoids many stat calls.

Regards,
Martin


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 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/

Any numbers?

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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
>> option (e.g. a HOWTO with the caveat "it worked on this particular
>> system").
>
>
> This should compare to zipping the standard library, which has been a
> supported
> configuration for a long time, and also avoids many stat calls.

Interestingly, I just did a quick test of this: This is on my Windows
7 PC, running under Powershell. D:\Apps\Python33 is a standard
installation, whereas D:\Dev\P33 has a zipped stdlib:

PS 22:02 D:\Data
>foreach ($i in 1..10) { measure-command { D:\Apps\Python33\python.exe -c 
>"raise SystemExit" } | % { $_.TotalSeconds } }
0.0737877
0.1014695
0.0950326
0.0910734
0.0689548
0.084994
0.0772204
0.0958197
0.0696385
0.0806066
PS 22:03 D:\Data
>foreach ($i in 1..10) { measure-command { D:\Dev\P33\python.exe -c "raise 
>SystemExit" } | % { $_.TotalSeconds } }
0.1922151
0.1879894
0.2455766
0.2842425
0.1937161
0.2168928
0.2441508
0.1860206
0.1866409
0.1897004

Looks like the normal configuration is over twice as fast as the zipped one...

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 main contributor.


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/


Any numbers?


No numbers, but I did see this talk:
http://2012.pyconuk.net/Talks/PyRun
The abstract claims that PyRun "has a greatly improved startup time 
compared to regular Python"


Cheers,
Mark

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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
> >>> spent, on a lower level. My gut feeling is that execution of Python
> >>> module code is the main contributor.
> >>
> >> 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/
> >
> > Any numbers?
> 
> No numbers, but I did see this talk:
> http://2012.pyconuk.net/Talks/PyRun
> The abstract claims that PyRun "has a greatly improved startup time 
> compared to regular Python"

Sounds great ;-)

cheers

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 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?
>>>
>>
>> The last time was between 3.2 and 3.3. It will be hard to lower the
>> number of imported modules, given the current semantics (io, importlib,
>> unicode, site.py, sysconfig...). Python 2's view of the world was much
>> simpler (naïve?) in comparison.
>>
>> 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 suspect that stating and loading the .pyc files is responsible for most
> of the overhead.
>

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).
More modules means more work (e.g. I/O, executing the module, etc.).

The only way to lower stat call overhead is to simply not check if a
directory's contents changed during startup by assuming Python itself will
not write any new module files. Without benchmarking I don't know if it
would make that much of a difference, though.


> PyRun starts up quite a lot faster thanks to embedding all the modules in
> the executable: 
> http://www.egenix.com/**products/python/PyRun/
>
> Freezing all the core modules into the executable should reduce start up
> time.
>

 Sure, but working with a frozen module is a pain so it is not something to
take lightly.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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
> >> significantly faster I'm thinking maybe it could become a semi-supported
> >> option (e.g. a HOWTO with the caveat "it worked on this particular
> >> system").
> >
> >
> > This should compare to zipping the standard library, which has been a
> > supported
> > configuration for a long time, and also avoids many stat calls.
>
> Interestingly, I just did a quick test of this: This is on my Windows
> 7 PC, running under Powershell. D:\Apps\Python33 is a standard
> installation, whereas D:\Dev\P33 has a zipped stdlib:
>
> PS 22:02 D:\Data
> >foreach ($i in 1..10) { measure-command { D:\Apps\Python33\python.exe -c
> "raise SystemExit" } | % { $_.TotalSeconds } }
> 0.0737877
> 0.1014695
> 0.0950326
> 0.0910734
> 0.0689548
> 0.084994
> 0.0772204
> 0.0958197
> 0.0696385
> 0.0806066
> PS 22:03 D:\Data
> >foreach ($i in 1..10) { measure-command { D:\Dev\P33\python.exe -c "raise
> SystemExit" } | % { $_.TotalSeconds } }
> 0.1922151
> 0.1879894
> 0.2455766
> 0.2842425
> 0.1937161
> 0.2168928
> 0.2441508
> 0.1860206
> 0.1866409
> 0.1897004
>
> Looks like the normal configuration is over twice as fast as the zipped
> one...
>

Are both debug builds (asking because of the path names)? CPython is now
significantly slower in a debug build thanks to the overhead it adds to any
Python code executing, which means importlib runs much slower.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 | grep -c stat

Python 2.7 - 161 stats
Python 3.2 - 555 stats
Python 3.3 - 243 stats


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 to caching filenames in a
> > directory).
> 
> $ strace ./python -c '' 2>&1 | grep -c stat
> 
> Python 2.7 - 161 stats
> Python 3.2 - 555 stats
> Python 3.3 - 243 stats

This will probably depend on the length of sys.path:

$ strace -e stat python2.7 -Sc "" 2>&1 | wc -l
35
$ strace -e stat python3.2 -Sc "" 2>&1 | wc -l
298
$ strace -e stat python3.3 -Sc "" 2>&1 | wc -l
106

$ strace -e stat python2.7 -c "" 2>&1 | wc -l
200
$ strace -e stat python3.2 -c "" 2>&1 | wc -l
726
$ strace -e stat python3.3 -c "" 2>&1 | wc -l
180

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 thresholds haven't been
tuned in ages afaik [or am i forgetting something] and I know of
pathological cases at work where simply doing a gc.disable() before
importing a bunch of modules (tons of generated protocol buffer code) and
re-enabling it afterwards speeds up this application's startup way more
significantly than seems healthy in 2.x... that could be related to the
particulars of the protobuf module code though.

-gps

On Sat, Oct 27, 2012 at 4:00 PM, Antoine Pitrou  wrote:

> 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 to caching filenames in a
> > > directory).
> >
> > $ strace ./python -c '' 2>&1 | grep -c stat
> >
> > Python 2.7 - 161 stats
> > Python 3.2 - 555 stats
> > Python 3.3 - 243 stats
>
> This will probably depend on the length of sys.path:
>
> $ strace -e stat python2.7 -Sc "" 2>&1 | wc -l
> 35
> $ strace -e stat python3.2 -Sc "" 2>&1 | wc -l
> 298
> $ strace -e stat python3.3 -Sc "" 2>&1 | wc -l
> 106
>
> $ strace -e stat python2.7 -c "" 2>&1 | wc -l
> 200
> $ strace -e stat python3.2 -c "" 2>&1 | wc -l
> 726
> $ strace -e stat python3.3 -c "" 2>&1 | wc -l
> 180
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com