Hi!
I have updated the branch benchmarks in the pyperformance server and now
they include 3.9. There are
some benchmarks that are faster but on the other hand some benchmarks are
substantially slower, pointing
at a possible performance regression in 3.9 in some aspects. In particular
some tests
My team has a python app that appears to perform 10+% better when the
python source is present v.s. when only the pyc's are distributed. This is
contradictory to my understanding of how python leverages pyc's.
Scenario
1. pyc-only install sees mediocre performance. (pyc's are built using
On Tue, Oct 7, 2014 at 12:46 PM, John Smith sanspriv...@gmail.com wrote:
pyc-only install sees mediocre performance. (pyc's are built using
compileall.py, then source .py's removed before packaging)
(Warning: it's been probably a decade since I looked at any of this
stuff, so treat this
On Tue Oct 07 2014 at 2:24:52 PM Skip Montanaro skip.montan...@gmail.com
wrote:
On Tue, Oct 7, 2014 at 12:46 PM, John Smith sanspriv...@gmail.com wrote:
pyc-only install sees mediocre performance. (pyc's are built using
compileall.py, then source .py's removed before packaging)
(Warning:
Hi,
On Wed, May 29, 2013 at 9:00 PM, Eric Snow ericsnowcurren...@gmail.com wrote:
...
What would be important to say in the devguide regarding Python
performance and testing it?
In the devguide I would only add information that are specific to
benchmarking the interpreter.
A separate
The devguide doesn't have anything on performance testing that I could
find. We do have a number of relatively useful resources in this
space though, like pybench and (eventually) speed.python.org. I'd
like to add a page to the devguide on performance testing, including
an explanation of our
Date: Wed, 29 May 2013 12:00:44 -0600
From: ericsnowcurren...@gmail.com
To: python-dev@python.org
Subject: [Python-Dev] performance testing recommendations in devguide
The devguide doesn't have anything on performance testing that I could
find. We do
Hi,
On Wed, 29 May 2013 12:00:44 -0600
Eric Snow ericsnowcurren...@gmail.com wrote:
The devguide doesn't have anything on performance testing that I could
find.
See http://bugs.python.org/issue17449
Tools I'm aware of:
* pybench (relatively limited in real-world usefulness)
* timeit
Hi,
On Wed, 29 May 2013 21:59:21 +0300
Carlos Nepomuceno carlosnepomuc...@outlook.com wrote:
[1] pybench - run the standard Python PyBench benchmark suite. This is
considered
an unreliable, unrepresentative benchmark; do not base decisions
off it. It is included only for completeness.
On Wed, May 29, 2013 at 9:19 PM, Antoine Pitrou solip...@pitrou.net wrote:
Hi,
On Wed, 29 May 2013 21:59:21 +0300
Carlos Nepomuceno carlosnepomuc...@outlook.com wrote:
[1] pybench - run the standard Python PyBench benchmark suite. This is
considered
an unreliable, unrepresentative
On 29.05.2013 21:19, Antoine Pitrou wrote:
Hi,
On Wed, 29 May 2013 21:59:21 +0300
Carlos Nepomuceno carlosnepomuc...@outlook.com wrote:
[1] pybench - run the standard Python PyBench benchmark suite. This is
considered
an unreliable, unrepresentative benchmark; do not base decisions
29.05.13 21:00, Eric Snow написав(ла):
Critically sensitive performance subjects
* interpreter start-up time
* module import overhead
* attribute lookup overhead (including MRO traversal)
* function call overhead
* instance creation overhead
* dict performance (the underlying namespace type)
*
Hi,
I posted this (by accident) off the list:
On 2012-11-14, at 23:43 , Chris Withers wrote:
On 14/11/2012 22:37, Chris Withers wrote:
On 14/11/2012 10:11, mar...@v.loewis.de wrote:
def xdict(**kwds):
return kwds
Hah, good call, this trumps both of the other options:
100 -r 5 -v
mar...@v.loewis.de wrote:
It's faster than calling dict() because the dict code will
create a second dictionary, and discard the keywords dictionary.
Perhaps in the case where dict() is called with keyword
args only, it could just return the passed-in keyword
dictionary instead of creating
Greg Ewing, 15.11.2012 11:48:
mar...@v.loewis.de wrote:
It's faster than calling dict() because the dict code will
create a second dictionary, and discard the keywords dictionary.
Perhaps in the case where dict() is called with keyword
args only, it could just return the passed-in keyword
Stefan Behnel stefan_ml at behnel.de writes:
Right. If that makes a difference, it's another bug.
Stefan
It's fixed, with, I will note, fewer lines of code than many messages in this
thread:
https://bitbucket.org/pypy/pypy/changeset/c30cb1dcb7a9adc32548fd14274e4995
Alex
On 11/15/2012 9:58 AM, Stefan Behnel wrote:
Greg Ewing, 15.11.2012 11:48:
mar...@v.loewis.de wrote:
It's faster than calling dict() because the dict code will
create a second dictionary, and discard the keywords dictionary.
Perhaps in the case where dict() is called with keyword
args only,
On 15/11/2012 4:21pm, Terry Reedy wrote:
I was thinking that CPython could check the ref count of the input
keyword dict to determine whether it is newly created and can be
returned or is pre-existing and must be copied. But it seems not so.
def d(**x): return sys.getrefcount(x)
import sys
Stefan Behnel wrote:
This should work as long as this still creates a copy of d at some point:
d = {...}
dict(**d)
It will -- the implementation of the function call opcode always
creates a new keyword dict for passing to the called function.
--
Greg
On Nov 14, 2012, at 5:37 PM, Chris Withers wrote:
On 14/11/2012 10:11, mar...@v.loewis.de wrote:
Zitat von Chris Withers ch...@simplistix.co.uk:
a_dict = dict(
x = 1,
y = 2,
z = 3,
...
)
What can we do to speed up the former case?
It should be possible to
Hi All,
A colleague pointed me at Doug's excellent article here:
http://www.doughellmann.com/articles/misc/dict-performance/index.html
...which made me a little sad, I suspect I'm not the only one who finds:
a_dict = dict(
x = 1,
y = 2,
z = 3,
...
)
...easier to read
Am 14.11.2012 10:12, schrieb Chris Withers:
Can someone with Python 3 handy compare there too?
C:\Python27\python -m timeit -n 100 -r 5 -v
dict(a=1, b=2, c=3, d=4, e=5, f=6, g=7)
raw times: 0.918 0.924 0.922 0.928 0.926
100 loops, best of 5: 0.918 usec per loop
C:\Python27\python
On 14/11/2012 09:58, Merlijn van Deen wrote:
On 14 November 2012 10:12, Chris Withers ch...@simplistix.co.uk wrote:
...which made me a little sad
Why did it make you sad? dict() takes 0.2µs, {} takes 0.04µs. In other
words: you can run dict() _five million_ times per second, and {}
Zitat von Chris Withers ch...@simplistix.co.uk:
a_dict = dict(
x = 1,
y = 2,
z = 3,
...
)
What can we do to speed up the former case?
It should be possible to special-case it. Rather than creating
a new dictionary from scratch, one could try to have the new dictionary
Le Wed, 14 Nov 2012 10:00:59 +,
Chris Withers ch...@simplistix.co.uk a écrit :
On 14/11/2012 09:58, Merlijn van Deen wrote:
On 14 November 2012 10:12, Chris Withers ch...@simplistix.co.uk
wrote:
...which made me a little sad
Why did it make you sad? dict() takes 0.2µs, {} takes
On 14/11/12 21:00, Chris Withers wrote:
On 14/11/2012 09:58, Merlijn van Deen wrote:
On 14 November 2012 10:12, Chris Withers ch...@simplistix.co.uk wrote:
...which made me a little sad
Why did it make you sad? dict() takes 0.2µs, {} takes 0.04µs. In other
words: you can run dict() _five
On Wed, Nov 14, 2012 at 8:12 PM, Chris Withers ch...@simplistix.co.uk wrote:
I suspect I'm not the only one who finds:
a_dict = dict(
x = 1,
y = 2,
z = 3,
...
)
...easier to read than:
a_dict = {
'x':1,
'y':2,
'z':3,
...
}
What can we do
2012/11/14 mar...@v.loewis.de:
Zitat von Chris Withers ch...@simplistix.co.uk:
a_dict = dict(
x = 1,
y = 2,
z = 3,
...
)
What can we do to speed up the former case?
It should be possible to special-case it. Rather than creating
a new dictionary from scratch,
Chris Angelico, 14.11.2012 14:18:
On Wed, Nov 14, 2012 at 8:12 PM, Chris Withers wrote:
I suspect I'm not the only one who finds:
a_dict = dict(
x = 1,
y = 2,
z = 3,
...
)
...easier to read than:
a_dict = {
'x':1,
'y':2,
'z':3,
...
}
What
On Wed, Nov 14, 2012 at 3:12 AM, Chris Withers ch...@simplistix.co.uk wrote:
Hi All,
A colleague pointed me at Doug's excellent article here:
...which made me a little sad, I suspect I'm not the only one who finds:
a_dict = dict(
x = 1,
y = 2,
z = 3,
...
)
On Wed, Nov 14, 2012 at 10:12:54AM -0600, Mark Adam dreamingforw...@gmail.com
wrote:
On Wed, Nov 14, 2012 at 3:12 AM, Chris Withers ch...@simplistix.co.uk wrote:
Hi All,
A colleague pointed me at Doug's excellent article here:
...which made me a little sad, I suspect I'm not the only one
On 14.11.12 11:12, Chris Withers wrote:
which made me a little sad, I suspect I'm not the only one who finds:
a_dict = dict(
x = 1,
y = 2,
z = 3,
...
)
easier to read than:
a_dict = {
'x':1,
'y':2,
'z':3,
...
}
PEP 8 recommends:
On 14/11/2012 4:23pm, Serhiy Storchaka wrote:
PEP 8 recommends:
a_dict = dict(
x=1,
y=2,
z=3,
...
)
and
a_dict = {
'x': 1,
'y': 2,
'z': 3,
...
}
In which section? I can't see such a recommendation.
--
Richard
On Wed, Nov 14, 2012 at 10:12 AM, Mark Adam dreamingforw...@gmail.com wrote:
On Wed, Nov 14, 2012 at 3:12 AM, Chris Withers ch...@simplistix.co.uk wrote:
Hi All,
A colleague pointed me at Doug's excellent article here:
...which made me a little sad, I suspect I'm not the only one who finds:
On 2012-11-14, at 17:42 , Richard Oudkerk wrote:
On 14/11/2012 4:23pm, Serhiy Storchaka wrote:
PEP 8 recommends:
a_dict = dict(
x=1,
y=2,
z=3,
...
)
and
a_dict = {
'x': 1,
'y': 2,
'z': 3,
...
}
In which section? I can't see such a
On Wed, Nov 14, 2012 at 11:02 AM, Xavier Morel python-...@masklinn.net wrote:
On 2012-11-14, at 17:42 , Richard Oudkerk wrote:
On 14/11/2012 4:23pm, Serhiy Storchaka wrote:
PEP 8 recommends:
a_dict = dict(
x=1,
y=2,
z=3,
...
)
and
a_dict = {
'x': 1,
'y':
On Wed, Nov 14, 2012 at 11:00 AM, Brian Curtin br...@python.org wrote:
On Wed, Nov 14, 2012 at 10:12 AM, Mark Adam dreamingforw...@gmail.com wrote:
On Wed, Nov 14, 2012 at 3:12 AM, Chris Withers ch...@simplistix.co.uk
wrote:
Hi All,
A colleague pointed me at Doug's excellent article here:
On Wed, 14 Nov 2012 11:10:15 -0600, Mark Adam dreamingforw...@gmail.com wrote:
On Wed, Nov 14, 2012 at 11:00 AM, Brian Curtin br...@python.org wrote:
On Wed, Nov 14, 2012 at 10:12 AM, Mark Adam dreamingforw...@gmail.com
wrote:
On Wed, Nov 14, 2012 at 3:12 AM, Chris Withers
On Wed, Nov 14, 2012 at 11:27 AM, R. David Murray rdmur...@bitdance.com wrote:
Maybe it's not good design, but I'll bet you that if it didn't do that,
there would be lots of instances of this scattered around various
codebases:
def makedict(**kw):
return kw
Now that's a good
On 14/11/2012 5:02pm, Xavier Morel wrote:
In which section? I can't see such a recommendation.
Whitespace in Expressions and Statements Other Recommendations
3rd bullet:
—
Don't use spaces around the = sign when used to indicate a keyword argument or
a default parameter value.
Oops, I
On 2012-11-14, at 18:08 , Mark Adam wrote:
That's not a recommendation to use the **kwargs style.
And nobody said it was. It's a recommendation to not put spaces around
the equals sign when using keyword arguments which is the correction
Serhiy applied to the original code (along with adding a
On 2012-11-14, at 18:10 , Mark Adam wrote:
Try the canonical {'x':1}. Only dict allows the special
initialization above. Other collections require an iterable.
Other collections don't have a choice, because it would often be
ambiguous. Dicts do not have that issue.
I'm guessing
**kwargs
On Wed, Nov 14, 2012 at 12:12 PM, Xavier Morel catch-...@masklinn.net wrote:
On 2012-11-14, at 18:10 , Mark Adam wrote:
Try the canonical {'x':1}. Only dict allows the special
initialization above. Other collections require an iterable.
Other collections don't have a choice, because it
On 2012-11-14, at 19:54 , Mark Adam wrote:
Merging of two dicts is done with dict.update.
No, dict.update merges one dict (or two) into a third one.
How do you do it on
initialization? This doesn't make sense.
dict(d1, **d2)
___
Python-Dev
On Thu, Nov 15, 2012 at 12:18:38AM +1100, Chris Angelico ros...@gmail.com
wrote:
On Wed, Nov 14, 2012 at 8:12 PM, Chris Withers ch...@simplistix.co.uk wrote:
I suspect I'm not the only one who finds:
a_dict = dict(
x = 1,
y = 2,
z = 3,
...
)
...easier to
On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel catch-...@masklinn.net wrote:
On 2012-11-14, at 19:54 , Mark Adam wrote:
Merging of two dicts is done with dict.update.
No, dict.update merges one dict (or two) into a third one.
No. I think you need to read the docs.
How do you do it on
On Wed, 14 Nov 2012 14:53:11 -0600
Mark Adam dreamingforw...@gmail.com wrote:
On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel catch-...@masklinn.net wrote:
On 2012-11-14, at 19:54 , Mark Adam wrote:
Merging of two dicts is done with dict.update.
No, dict.update merges one dict (or two)
On 2012-11-14 20:53, Mark Adam wrote:
On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel catch-...@masklinn.net wrote:
On 2012-11-14, at 19:54 , Mark Adam wrote:
Merging of two dicts is done with dict.update.
No, dict.update merges one dict (or two) into a third one.
No. I think you need to
On 2012-11-14 21:20, MRAB wrote:
On 2012-11-14 20:53, Mark Adam wrote:
On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel catch-...@masklinn.net wrote:
On 2012-11-14, at 19:54 , Mark Adam wrote:
Merging of two dicts is done with dict.update.
No, dict.update merges one dict (or two) into a third
On Wed, Nov 14, 2012 at 3:20 PM, MRAB pyt...@mrabarnett.plus.com wrote:
On 2012-11-14 20:53, Mark Adam wrote:
On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel catch-...@masklinn.net
wrote:
On 2012-11-14, at 19:54 , Mark Adam wrote:
Merging of two dicts is done with dict.update.
No,
MRAB wrote:
On 2012-11-14 20:53, Mark Adam wrote:
On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel catch-...@masklinn.net
wrote:
On 2012-11-14, at 19:54 , Mark Adam wrote:
Merging of two dicts is done with dict.update.
No, dict.update merges one dict (or two) into a third one.
No. I think
To (mis-)quote Antoine:
-- d1 = {1:2}
-- d2 = {'3':4}
-- dict(d1, **d2)
{1: 2, '3': 4}
Apparently it is valid syntax. Just make sure you keys for the **
operator are valid strings. :)
or not:
dict(**{'not a valid identifier': True, 1: True})
{1: True, 'not a valid identifier':
On Wed, Nov 14, 2012 at 3:40 PM, Brandon W Maister bwmais...@gmail.com wrote:
To (mis-)quote Antoine:
-- d1 = {1:2}
-- d2 = {'3':4}
-- dict(d1, **d2)
{1: 2, '3': 4}
Apparently it is valid syntax. Just make sure you keys for the **
operator are valid strings. :)
or not:
On 2012-11-14, at 21:53 , Mark Adam wrote:
On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel catch-...@masklinn.net wrote:
On 2012-11-14, at 19:54 , Mark Adam wrote:
Merging of two dicts is done with dict.update.
No, dict.update merges one dict (or two) into a third one.
No. I think you
Chris Angelico wrote:
Perhaps an alternative question: What can be done to make the latter
less unpalatable?
* We could introduce a new syntax such as {a = 1, b = 2}.
* If the compiler were allowed to recognise builtins, it could
turn dict(a = 1, b = 2) into {'a':1, 'b':2} automatically.
--
On 14/11/2012 10:11, mar...@v.loewis.de wrote:
Zitat von Chris Withers ch...@simplistix.co.uk:
a_dict = dict(
x = 1,
y = 2,
z = 3,
...
)
What can we do to speed up the former case?
It should be possible to special-case it. Rather than creating
a new dictionary from
On 14/11/2012 21:40, Greg Ewing wrote:
* If the compiler were allowed to recognise builtins, it could
turn dict(a = 1, b = 2) into {'a':1, 'b':2} automatically.
That would be my naive suggestion, I am prepared to be shot down in
flames ;-)
Would be even more awesome if it could end up with
On 14/11/2012 22:37, Chris Withers wrote:
On 14/11/2012 10:11, mar...@v.loewis.de wrote:
def xdict(**kwds):
return kwds
Hah, good call, this trumps both of the other options:
$ python2.7 -m timeit -n 100 -r 5 -v
{'a':1,'b':2,'c':3,'d':4,'e':5,'f':6,'g':7}
raw times: 1.45 1.45 1.44
On 2012-11-14 21:40, Greg Ewing wrote:
Chris Angelico wrote:
Perhaps an alternative question: What can be done to make the latter
less unpalatable?
* We could introduce a new syntax such as {a = 1, b = 2}.
* If the compiler were allowed to recognise builtins, it could
turn dict(a = 1, b = 2)
$ pypy -m timeit 'dict()'
10 loops, best of 3: 0.000811 usec per loop
$ pypy -m timeit '{}'
10 loops, best of 3: 0.000809 usec per loop
$ pypy -m timeit 'def md(**kw): return kw; md()'
1 loops, best of 3: 0.0182 usec per loop
$ pypy -m timeit -s 'def md(**kw): return
On 2012-11-14, at 23:43 , Chris Withers wrote:
On 14/11/2012 22:37, Chris Withers wrote:
On 14/11/2012 10:11, mar...@v.loewis.de wrote:
def xdict(**kwds):
return kwds
Hah, good call, this trumps both of the other options:
$ python2.7 -m timeit -n 100 -r 5 -v
On 15/11/12 05:54, Mark Adam wrote:
Merging of two dicts is done with dict.update. How do you do it on
initialization? This doesn't make sense.
Frequently.
my_prefs = dict(default_prefs, setting=True, another_setting=False)
Notice that I'm not merging one dict into another, but merging
Notice that {'x':1} and dict(x=1) are different beasts: The first one
compiles directly to BUILD_MAP. The second one loads a reference to 'dict'
from globals() and calls the constructor. The two are not the same.
2012/11/15 Steven D'Aprano st...@pearwood.info
On 15/11/12 05:54, Mark Adam
On Thu, Nov 15, 2012 at 10:36 AM, Steven D'Aprano st...@pearwood.info wrote:
On 15/11/12 05:54, Mark Adam wrote:
Merging of two dicts is done with dict.update. How do you do it on
initialization? This doesn't make sense.
Frequently.
my_prefs = dict(default_prefs, setting=True,
On 11/14/2012 4:12 AM, Chris Withers wrote:
To somewhat paraphrase: '''
I prefer 'dict(a=1,b=2,c=3,d=4,e=5,f=6,g=7)' to
{'a':1,'b':2,'c':3,'d':4,'e':5,'f':6,'g':7}.
I am sad that the former takes +-2 times as long to run (in 2.7).
Is the difference about the same in 3.x?
What can we do to speed
On Wed, Nov 14, 2012 at 5:40 PM, Chris Angelico ros...@gmail.com wrote:
On Thu, Nov 15, 2012 at 10:36 AM, Steven D'Aprano st...@pearwood.info wrote:
On 15/11/12 05:54, Mark Adam wrote:
Notice that I'm not merging one dict into another, but merging two dicts
into a third.
Side point: Wouldn't
Chris Angelico writes:
{a:1}+{b:2}
It would make sense for this to result in {a:1,b:2}.
The test is not does this sometimes make sense? It's does this
ever result in nonsense, and if so, do we care?
Here, addition is usually commutative. Should {'a':1}+{'a':2} be the
same as, or
On Thu, Nov 15, 2012 at 1:28 PM, Stephen J. Turnbull step...@xemacs.org wrote:
Chris Angelico writes:
{a:1}+{b:2}
It would make sense for this to result in {a:1,b:2}.
The test is not does this sometimes make sense? It's does this
ever result in nonsense, and if so, do we care?
On Wed, Nov 14, 2012 at 8:28 PM, Stephen J. Turnbull step...@xemacs.org wrote:
Chris Angelico writes:
{a:1}+{b:2}
It would make sense for this to result in {a:1,b:2}.
The test is not does this sometimes make sense? It's does this
ever result in nonsense, and if so, do we care?
Chris Angelico writes:
On Thu, Nov 15, 2012 at 1:28 PM, Stephen J. Turnbull step...@xemacs.org
wrote:
Chris Angelico writes:
{a:1}+{b:2}
It would make sense for this to result in {a:1,b:2}.
The test is not does this sometimes make sense? It's does this
ever
Mark Adam writes:
Easy: dict should have a (user substitutable) collision function that
is called in these cases.
I smell overengineering.
This would allow significant functionality with practically no
cost.
We already have that functionality if we want it; just define an
appropriate
Zitat von Chris Withers ch...@simplistix.co.uk:
On 14/11/2012 21:40, Greg Ewing wrote:
* If the compiler were allowed to recognise builtins, it could
turn dict(a = 1, b = 2) into {'a':1, 'b':2} automatically.
That would be my naive suggestion, I am prepared to be shot down in
flames ;-)
Zitat von Chris Withers ch...@simplistix.co.uk:
$ python2.7 -m timeit -n 100 -r 5 -v
{'a':1,'b':2,'c':3,'d':4,'e':5,'f':6,'g':7}
raw times: 1.49 1.49 1.5 1.49 1.48
100 loops, best of 5: 1.48 usec per loop
$ python2.7 -m timeit -n 100 -r 5 -v 'dict(a=1,b=2,c=3,d=4,e=5,f=6,g=7)'
Zitat von Chris Angelico ros...@gmail.com:
On Thu, Nov 15, 2012 at 1:28 PM, Stephen J. Turnbull
step...@xemacs.org wrote:
Chris Angelico writes:
{a:1}+{b:2}
It would make sense for this to result in {a:1,b:2}.
The test is not does this sometimes make sense? It's does this
ever
Donald Stufft, 15.11.2012 00:00:
$ pypy -m timeit 'dict()'
10 loops, best of 3: 0.000811 usec per loop
$ pypy -m timeit '{}'
10 loops, best of 3: 0.000809 usec per loop
$ pypy -m timeit 'def md(**kw): return kw; md()'
1 loops, best of 3: 0.0182 usec per loop
On 15/11/2012 06:32, Stefan Behnel wrote:
Donald Stufft, 15.11.2012 00:00:
$ pypy -m timeit 'dict()'
10 loops, best of 3: 0.000811 usec per loop
$ pypy -m timeit '{}'
10 loops, best of 3: 0.000809 usec per loop
$ pypy -m timeit 'def md(**kw): return kw; md()'
1 loops,
Chris Withers, 15.11.2012 08:14:
On 15/11/2012 06:32, Stefan Behnel wrote:
Donald Stufft, 15.11.2012 00:00:
$ pypy -m timeit 'dict()'
10 loops, best of 3: 0.000811 usec per loop
$ pypy -m timeit '{}'
10 loops, best of 3: 0.000809 usec per loop
$ pypy -m timeit 'def
On 15.11.12 01:47, Terry Reedy wrote:
4. There are about 3000 issues on the tracker. Nearly all are worth more
attention than this ;-).
This is the best conclusion of this thread.
___
Python-Dev mailing list
Python-Dev@python.org
Antoine Pitrou, 08.03.2012 21:36:
On Thu, 8 Mar 2012 14:36:06 -0600
Benjamin Peterson wrote:
2012/3/8 Stefan Behnel:
Would that be acceptable for CPython as well or would you prefer full
fledged normalisation?
I think we have to normalize for correctness. Consider that it may be
some
On Sat, 25 Feb 2012 19:13:26 -0800
Guido van Rossum gu...@python.org wrote:
If this can encourage more projects to support Python 3 (even if it's
only 3.3 and later) and hence improve adoption of Python 3, I'm all
for it.
A small quibble: I'd like to see a benchmark of a 'u' function
Neal Norwitz nnorwitz at gmail.com writes:
Can someone (else) compare performance of 2.5, 2.6, and 3.0?
Tests done on a 32-bit Linux installation on an Athlon 3600+ X2. Compiled with
gcc in UCS2 mode.
pystone
---
- 2.5: 43859.6 pystones/second
- 2.6: 42016.8 pystones/second
- 3.0: 38759.7
Thanks Antoine!
On Sun, Aug 24, 2008 at 5:58 AM, Antoine Pitrou [EMAIL PROTECTED] wrote:
Neal Norwitz nnorwitz at gmail.com writes:
Can someone (else) compare performance of 2.5, 2.6, and 3.0?
Tests done on a 32-bit Linux installation on an Athlon 3600+ X2. Compiled with
gcc in UCS2 mode.
Hi,
So 3.0 is about 10% slower than 2.x. Given all the changes, that
doesn't seem too bad.
Yes, I think it's rather good.
- 2.5: 770.54 ms per iteration
- 2.6: 572.84 ms per iteration
- 3.0: 566.69 ms per iteration
I'm a little concerned about why the big change here. Though if
Antoine Pitrou schrieb:
Hi,
pystone
---
- 2.5: 43859.6 pystones/second
- 2.6: 42016.8 pystones/second
- 3.0: 38759.7 pystones/second
So 3.0 is about 10% slower than 2.x. Given all the changes, that
doesn't seem too bad.
Yes, I think it's rather good.
Well, pystone really doesn't
On Mon, 25 Aug 2008 05:04:16 am Antoine Pitrou wrote:
CompareFloatsIntegers: 274ms 274ms 0.30us
0.630ms
Much slower, but probably due to switch from int - long. There
could be potential for optimizing this case.
Well honestly you don't often compare different
85 matches
Mail list logo
