On 3 Apr, 2009, at 0:57, Guido van Rossum wrote:
The primary use case is some kind of trap on assignment. While this
cannot cover all cases, most non-local variables are stored in dicts.
List mutations are not in the same league, as use case.
I have a slightly different use-case than a
On Fri, Apr 03, 2009, Collin Winter wrote:
I don't believe that these are insurmountable problems, though. A
great contribution to Python performance work would be an improved
version of PyBench that corrects these problems and offers more
precise measurements. Is that something you might be
Thomas Wouters thomas at python.org writes:
Pystone is pretty much a useless benchmark. If it measures anything, it's the
speed of the bytecode dispatcher (and it doesn't measure it particularly well.)
PyBench isn't any better, in my experience.
I don't think pybench is useless. It gives a
On Fri, Apr 3, 2009 at 11:27, Antoine Pitrou solip...@pitrou.net wrote:
Thomas Wouters thomas at python.org writes:
Pystone is pretty much a useless benchmark. If it measures anything, it's
the
speed of the bytecode dispatcher (and it doesn't measure it particularly
well.)
PyBench
On Fri, Apr 3, 2009 at 2:27 AM, Antoine Pitrou solip...@pitrou.net wrote:
Thomas Wouters thomas at python.org writes:
Pystone is pretty much a useless benchmark. If it measures anything, it's the
speed of the bytecode dispatcher (and it doesn't measure it particularly
well.)
PyBench isn't
I think it's worse to give the poor guy the run around
by making him run lots of random benchmarks.
the poor guy works for Wingware (a company you may have
heard of) and has contributed to Python at several occasions.
His name is John Ehresmann.
In the end, someone will run a timeit or have a
Thomas Wouters thomas at python.org writes:
Really? Have you tried it? I get at least 5% noise between runs without any
changes. I have gotten results that include *negative* run times.
That's an implementation problem, not an issue with the tests themselves.
Perhaps a better timing mechanism
Just want to reply quickly because I'm traveling -- I appreciate the
feedback from Raymond and others. Part of the reason I created an issue
with a proof of concept patch is to get this kind of feedback. I also
agree that this shouldn't go in if it slows things down noticeably.
I will do
On 2009-04-03 18:06, Thomas Wouters wrote:
On Fri, Apr 3, 2009 at 11:27, Antoine Pitrou solip...@pitrou.net wrote:
Thomas Wouters thomas at python.org writes:
Pystone is pretty much a useless benchmark. If it measures anything, it's
the
speed of the bytecode dispatcher (and it doesn't
On Fri, Apr 3, 2009 at 9:43 AM, Antoine Pitrou solip...@pitrou.net wrote:
Thomas Wouters thomas at python.org writes:
Really? Have you tried it? I get at least 5% noise between runs without any
changes. I have gotten results that include *negative* run times.
That's an implementation
Collin Winter wrote:
On Fri, Apr 3, 2009 at 2:27 AM, Antoine Pitrou solip...@pitrou.net wrote:
Thomas Wouters thomas at python.org writes:
Pystone is pretty much a useless benchmark. If it measures anything, it's the
speed of the bytecode dispatcher (and it doesn't measure it
On Fri, Apr 3, 2009 at 10:28 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
Collin Winter wrote:
As part of the common standard library and test suite that we agreed
on at the PyCon language summit last week, we're going to include a
common benchmark suite that all Python implementations
Collin Winter collinw at gmail.com writes:
- I wish PyBench actually did more isolation.
Call.py:ComplexPythonFunctionCalls is on my mind right now; I wish it
didn't put keyword arguments and **kwargs in the same microbenchmark.
Well, there is a balance to be found between having more
On Fri, Apr 3, 2009 at 10:50 AM, Antoine Pitrou solip...@pitrou.net wrote:
Collin Winter collinw at gmail.com writes:
- I wish PyBench actually did more isolation.
Call.py:ComplexPythonFunctionCalls is on my mind right now; I wish it
didn't put keyword arguments and **kwargs in the same
; python-dev@python.org
Sent: Thursday, April 02, 2009 2:19 PM
Subject: Re: [Python-Dev] PyDict_SetItem hook
Wow. Can you possibly be more negative?
2009/4/2 Raymond Hettinger pyt...@rcn.com:
The measurements are just a distractor. We all already know that the hook
is being added
On Thu, Apr 2, 2009 at 04:16, John Ehresman j...@wingware.com wrote:
Collin Winter wrote:
Have you measured the impact on performance?
I've tried to test using pystone, but am seeing more differences between
runs than there is between python w/ the patch and w/o when there is no hook
The measurements are just a distractor. We all already know that the hook is
being added to a critical path. Everyone will pay a cost for a feature that
few people will use. This is a really bad idea. It is not part of a thorough,
thought-out framework of container hooks (something that
tho...@python.org; John Ehresman j...@wingware.com;
python-dev@python.org
Sent: Thursday, April 02, 2009 2:19 PM
Subject: Re: [Python-Dev] PyDict_SetItem hook
Wow. Can you possibly be more negative?
2009/4/2 Raymond Hettinger pyt...@rcn.com:
The measurements are just a distractor. We all
Raymond Hettinger python at rcn.com writes:
It seems weird to me that Collin's group can be working
so hard just to get a percent or two improvement in
specific cases for pickling while python-dev is readily
entertaining a patch that slows down the entire language.
I think it's really
It seems weird to me that Collin's group can be working
so hard just to get a percent or two improvement in
specific cases for pickling while python-dev is readily
entertaining a patch that slows down the entire language.
[Antoine Pitrou]
I think it's really more than a percent or two:
On Thu, Apr 2, 2009 at 03:23, Christian Heimes li...@cheimes.de wrote:
John Ehresman wrote:
* To what extent should non-debugger code use the hook? At one end of
the spectrum, the hook could be made readily available for non-debug use
and at the other end, it could be documented as being
On Fri, Apr 3, 2009 at 00:07, Raymond Hettinger pyt...@rcn.com wrote:
It seems weird to me that Collin's group can be working
so hard just to get a percent or two improvement in specific cases for
pickling while python-dev is readily entertaining a patch that slows down
the entire language.
Subject: Re: [Python-Dev] PyDict_SetItem hook
Wow. Can you possibly be more negative?
2009/4/2 Raymond Hettinger pyt...@rcn.com:
The measurements are just a distractor. We all already know that the hook
is being added to a critical path. Everyone will pay a cost for a feature
that few
On Wed, Apr 1, 2009 at 4:29 PM, John Ehresman j...@wingware.com wrote:
I've written a proof of concept patch to add a hook to PyDict_SetItem at
http://bugs.python.org/issue5654 My motivation is to enable watchpoints in
a python debugger that are called when an attribute or global changes. I
John Ehresman wrote:
* To what extent should non-debugger code use the hook? At one end of
the spectrum, the hook could be made readily available for non-debug use
and at the other end, it could be documented as being debug only,
disabled in python -O, not exposed in the stdlib to python
John Ehresman wrote:
* To what extent should non-debugger code use the hook? At one end of
the spectrum, the hook could be made readily available for non-debug use
and at the other end, it could be documented as being debug only,
disabled in python -O, not exposed in the stdlib to python
Collin Winter wrote:
Have you measured the impact on performance?
I've tried to test using pystone, but am seeing more differences between
runs than there is between python w/ the patch and w/o when there is no
hook installed. The highest pystone is actually from the binary w/ the
patch,
27 matches
Mail list logo
