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 debu
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
t; source of negativity. I just happen to think this proposal isn't a good
>> idea.
>
> I think we need more proof either way.
>
>> Raymond
>>
>>
>>
>> - Original Message - From: "Guido van Rossum"
>> To: "Raymond He
On Fri, Apr 3, 2009 at 12:28 PM, Michael Foord
wrote:
> Collin Winter wrote:
>>
>> On Fri, Apr 3, 2009 at 2:27 AM, Antoine Pitrou
>> wrote:
>>
>>>
>>> Thomas Wouters python.org> writes:
>>>
Pystone is pretty much a useless benchmark. If it measures anything,
it's the
>>>
>>>
On Fri, Apr 3, 2009 at 10:50 AM, Antoine Pitrou wrote:
> Collin Winter 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,
Collin Winter wrote:
On Fri, Apr 3, 2009 at 10:28 AM, Michael Foord
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 implementation
Collin Winter 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 subtests and
On Fri, Apr 3, 2009 at 10:28 AM, Michael Foord
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 can share. This
>> i
Collin Winter wrote:
On Fri, Apr 3, 2009 at 2:27 AM, Antoine Pitrou wrote:
Thomas Wouters 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 i
On Fri, Apr 3, 2009 at 9:43 AM, Antoine Pitrou wrote:
> Thomas Wouters 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
On 2009-04-03 18:06, Thomas Wouters wrote:
> On Fri, Apr 3, 2009 at 11:27, Antoine Pitrou wrote:
>
>> Thomas Wouters 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 particu
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 som
Thomas Wouters 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 could b
> 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 ha
On Fri, Apr 3, 2009 at 2:27 AM, Antoine Pitrou wrote:
> Thomas Wouters 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
On Fri, Apr 3, 2009 at 11:27, Antoine Pitrou wrote:
> Thomas Wouters 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
Thomas Wouters 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 lot of
rom the thread. I don't aspire to be a
> source of negativity. I just happen to think this proposal isn't a good
> idea.
I think we need more proof either way.
> Raymond
>
>
>
> - Original Message - From: "Guido van Rossum"
> To: "Raym
On Fri, Apr 3, 2009 at 00:07, Raymond Hettinger 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.
Collin's
On Thu, Apr 2, 2009 at 03:23, Christian Heimes 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 debug only,
>>
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:
ht
Raymond Hettinger 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 more
"
Cc: "Thomas Wouters" ; "John Ehresman" ;
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 :
The measurements are just a distractor. We all already know that the hook
Wow. Can you possibly be more negative?
2009/4/2 Raymond Hettinger :
> 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
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 woul
On Thu, Apr 2, 2009 at 04:16, John Ehresman 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
> installed.
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, wh
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 cod
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
On Wed, Apr 1, 2009 at 4:29 PM, John Ehresman 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
> know that thi
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 know that this won't cover function locals and
objects with slots (as M
31 matches
Mail list logo
