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 li
On Tue Oct 07 2014 at 2:24:52 PM Skip Montanaro
wrote:
> On Tue, Oct 7, 2014 at 12:46 PM, John Smith 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 look
On Tue, Oct 7, 2014 at 12:46 PM, John Smith 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 response as mere conjecture
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
compile
Hi,
On Wed, May 29, 2013 at 9:00 PM, Eric Snow 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 "Benchmarking HOWTO" that cover
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)
* tu
On 29.05.2013 21:19, Antoine Pitrou wrote:
>
> Hi,
>
> On Wed, 29 May 2013 21:59:21 +0300
> Carlos Nepomuceno 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 i
On Wed, May 29, 2013 at 9:19 PM, Antoine Pitrou wrote:
>
> Hi,
>
> On Wed, 29 May 2013 21:59:21 +0300
> Carlos Nepomuceno wrote:
>>
>> [1] "pybench - run the standard Python PyBench benchmark suite. This is
>> considered
>> an unreliable, unrepresentative benchmark; do not base decisions
>> off
Hi,
On Wed, 29 May 2013 21:59:21 +0300
Carlos Nepomuceno 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."
"unrepresentative" is th
Hi,
On Wed, 29 May 2013 12:00:44 -0600
Eric Snow 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 module (for quick comparisio
> 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 test
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 perf
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 :
>>
>>> a_dict = dict(
>>>x = 1,
>>>y = 2,
>>>z = 3,
>>>...
>>>)
>>
>>> What can we do to speed up the former case?
>>
>> It should be possible
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 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)
>>> impor
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, it
Stefan Behnel 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
__
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 ke
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 anot
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
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
http://mail.python.o
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
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, b
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
Zitat von Chris Angelico :
On Thu, Nov 15, 2012 at 1:28 PM, Stephen J. Turnbull
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
Zitat von Chris Withers :
$ 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)'
raw times: 2.35 2.36 2
Zitat von Chris Withers :
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 ;-)
In general, special-ca
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
appropr
Chris Angelico writes:
> On Thu, Nov 15, 2012 at 1:28 PM, Stephen J. Turnbull
> 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
On Wed, Nov 14, 2012 at 8:28 PM, Stephen J. Turnbull 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 Thu, Nov 15, 2012 at 1:28 PM, Stephen J. Turnbull 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:
> >>> {"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
sam
On Wed, Nov 14, 2012 at 5:40 PM, Chris Angelico wrote:
> On Thu, Nov 15, 2012 at 10:36 AM, Steven D'Aprano 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 it be quite logical to sup
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 Thu, Nov 15, 2012 at 10:36 AM, Steven D'Aprano 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, another_setting=F
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
> On 15/11/12 05:54, Mark Adam wrote:
>
> Merging of
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 t
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
>> "{
$ 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 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)
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 1.
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 t
On 14/11/2012 10:11, mar...@v.loewis.de wrote:
Zitat von Chris Withers :
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
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.
--
G
On 2012-11-14, at 21:53 , Mark Adam wrote:
> On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel 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 r
On Wed, Nov 14, 2012 at 3:40 PM, Brandon W Maister 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:
>
>
> 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 val
MRAB wrote:
On 2012-11-14 20:53, Mark Adam wrote:
On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel
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 do
On Wed, Nov 14, 2012 at 3:20 PM, MRAB wrote:
> On 2012-11-14 20:53, Mark Adam wrote:
>>
>> On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel
>> wrote:
>>>
>>> On 2012-11-14, at 19:54 , Mark Adam wrote:
Merging of two dicts is done with dict.update.
>>>
>>>
>>> No, dict.update merges on
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 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 yo
On 2012-11-14 20:53, Mark Adam wrote:
On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel 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
On Wed, 14 Nov 2012 14:53:11 -0600
Mark Adam wrote:
> On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel 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 y
On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel 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
>> initialization?
On Thu, Nov 15, 2012 at 12:18:38AM +1100, Chris Angelico
wrote:
> 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:
> >
> >
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 ma
On Wed, Nov 14, 2012 at 12:12 PM, Xavier Morel 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 would often be
>
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
> **kw
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
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 d
On Wed, Nov 14, 2012 at 11:27 AM, R. David Murray 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 solution and probab
On Wed, 14 Nov 2012 11:10:15 -0600, Mark Adam wrote:
> On Wed, Nov 14, 2012 at 11:00 AM, Brian Curtin wrote:
> > On Wed, Nov 14, 2012 at 10:12 AM, Mark Adam
> > wrote:
> >> On Wed, Nov 14, 2012 at 3:12 AM, Chris Withers
> >> wrote:
> >>> Hi All,
> >>>
> >>> A colleague pointed me at Doug's ex
On Wed, Nov 14, 2012 at 11:00 AM, Brian Curtin wrote:
> On Wed, Nov 14, 2012 at 10:12 AM, Mark Adam wrote:
>> On Wed, Nov 14, 2012 at 3:12 AM, Chris Withers
>> wrote:
>>> Hi All,
>>>
>>> A colleague pointed me at Doug's excellent article here:
>>> ...which made me a little sad, I suspect I'm no
On Wed, Nov 14, 2012 at 11:02 AM, Xavier Morel 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 = {
>>>
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 s
On Wed, Nov 14, 2012 at 10:12 AM, Mark Adam wrote:
> On Wed, Nov 14, 2012 at 3:12 AM, Chris Withers 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,
>>
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 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:
a_di
On Wed, Nov 14, 2012 at 10:12:54AM -0600, Mark Adam
wrote:
> On Wed, Nov 14, 2012 at 3:12 AM, Chris Withers 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(
> >
On Wed, Nov 14, 2012 at 3:12 AM, Chris Withers 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,
> ...
> )
>
> ...easier to read
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,
>>
2012/11/14 :
>
> Zitat von Chris Withers :
>
>
>> 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 h
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 can we do to sp
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 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,
Le Wed, 14 Nov 2012 10:00:59 +,
Chris Withers a écrit :
> On 14/11/2012 09:58, Merlijn van Deen wrote:
> > On 14 November 2012 10:12, Chris Withers
> > 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 r
Zitat von Chris Withers :
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
the same size as the or
On 14/11/2012 09:58, Merlijn van Deen wrote:
On 14 November 2012 10:12, Chris Withers 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 {}
twenty-five million times per sec
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
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 than:
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 b
On Sat, 25 Feb 2012 19:13:26 -0800
Guido van Rossum 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 implemented in
> C
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
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 does
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. Tho
Thanks Antoine!
On Sun, Aug 24, 2008 at 5:58 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Neal Norwitz 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.
>
> p
Neal Norwitz 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 pystones/
On 3/2/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> We can get more than half of the benefit simply by using a default
> __init__ rather than a python one. If you need custom attributes but
> they're predefined you could subclass the exception and have them as
> class attributes. Given that, is th
Often people build mental models of performance that have little
bearing on reality. Thanks for measuring!
On 3/2/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> $ python2.5 -m timeit -r 10 -n 100 -s 'class Foo(Exception): pass'
> 'try: raise Foo()' 'except: pass'
> 100 loops, best of 10: 2.49
$ python2.5 -m timeit -r 10 -n 100 -s 'class Foo(Exception): pass'
'try: raise Foo()' 'except: pass'
100 loops, best of 10: 2.49 usec per loop
$ python2.5 -m timeit -r 10 -n 100 -s 'class Foo(Exception):' -s '
def __init__(self): pass' 'try: raise Foo()' 'except: pass'
100 loops, b
88 matches
Mail list logo
