[Raymond Hettinger]
> > With respect to
> > distribution, it should be noted that string hash values are decidely
> > non-random and your variable names likely congested consecutive spaces
> > in a nearly full table (resulting in seven times as many search probes
> > to find a global value).
> >
>
Raymond Hettinger wrote:
>
> Mark Dickinson wrote:
>> I have a simple 192-line Python script that begins with the line:
>>
>> dummy0 = 47
>>
>> The script runs in less than 2.5 seconds. The variable dummy0 is never
>> referenced again, directly or indirectly, by the rest of the script.
>>
>> Her
> I've learnt my lesson :) Thank you for your help, and apologies
> for wasting other people's time with this as well as my own!
I've learnt my lesson reading through this thread, too.
I am glad to be given the chance of wasting my time
with it and very happy and thankful, that you posted
your
Two observations:
1 - The difference in run time with and without the dummy* globals is
due to a difference in the number of invokations of the search()
function: 1,140 resp. 27,530 in my environment.
To verify, just change the line
def search():
to
searches = 0
def search():
Stelios Xanthakis wrote:
> Mark Dickinson wrote:
>
>> I have a simple 192-line Python script that begins with the line:
>>
>> dummy0 = 47
>>
>> The script runs in less than 2.5 seconds. The variable dummy0 is never
>> referenced again, directly or indirectly, by the rest of the script.
>>
>> Here
Mark Dickinson wrote:
> I have a simple 192-line Python script that begins with the line:
>
> dummy0 = 47
>
> The script runs in less than 2.5 seconds. The variable dummy0 is never
> referenced again, directly or indirectly, by the rest of the script.
>
> Here's the surprise: if I remove or comme
In article <[EMAIL PROTECTED]>, Bill
Mill <[EMAIL PROTECTED]> wrote:
> I'm also pretty sure I've caught a bug in his code, though I'm not
> sure how it works exactly. I replaced the 'min' built-in with my own
> min, and he's going to get nondeterministic results from this line:
>
>mm =
In article <[EMAIL PROTECTED]>,
Stelios Xanthakis <[EMAIL PROTECTED]> wrote:
> In the sudoku solver, there is a min (number, object) which is
> probably what's affected by the extistance of the dummy variable.
> Now, in sudoku puzzles some times the algorithm has to suppose
> that in a box the r
On 8/25/05, Jack Diederich <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 25, 2005 at 09:23:09PM +0300, Stelios Xanthakis wrote:
> > The explanation is this: hash
> > and comparison of objects depends on the state of the memory
> > allocator. A sample case is this:
> >
> > class A: pass
> >
On Thu, Aug 25, 2005 at 09:23:09PM +0300, Stelios Xanthakis wrote:
> The explanation is this: hash
> and comparison of objects depends on the state of the memory
> allocator. A sample case is this:
>
> class A: pass
> dummy0=47 # comment this to get a different result for min
>
On 8/25/05, Erik Max Francis <[EMAIL PROTECTED]> wrote:
> Bill Mill wrote:
>
> > Unlikely; 2 people have confirmed these results already.
> >
> > I did find, though, that if I remove all print statements from the
> > program, the dummy and non-dummy variable versions take indentical
> > time. Can
Mark Dickinson wrote:
> I have a simple 192-line Python script that begins with the line:
>
> dummy0 = 47
>
> The script runs in less than 2.5 seconds. The variable dummy0 is never
> referenced again, directly or indirectly, by the rest of the script.
>
> Here's the surprise: if I remove or com
On 8/25/05, Jack Diederich <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 25, 2005 at 01:35:04PM -0400, Bill Mill wrote:
> > On 8/25/05, Erik Max Francis <[EMAIL PROTECTED]> wrote:
> > > Mark Dickinson wrote:
> > >
> > > > Questions:
> > > >
> > > > (1) Can anyone else reproduce this behaviour, or is it
On Thu, Aug 25, 2005 at 01:55:48PM -0400, Bill Mill wrote:
> Bill Mill wrote:
> >
> > Pentium M 1.8 GHz Windows 2k. Here's the top of the profile results
> > for fast and slow on my machine (these won't look decent except in a
> > fixed-width font):
> >
>
> >
> > Interestingly, the test.py:36 li
Mark Dickinson wrote:
> Questions:
> (1) Can anyone else reproduce this behaviour, or is it just some quirk
> of my setup?
yes. I get 7 sec vs 1 sec on my laptop.
> (2) Any possible explanations? Is there some optimization that kicks
> in at a certain number of lines, or at a certain le
In article <[EMAIL PROTECTED]>, Bill
Mill <[EMAIL PROTECTED]> wrote:
> One of my own: what in the world made you think "maybe I'll add 29
> dummy global variables to speed things up?"
You mean this isn't a well-known optimization technique? :)
I was refactoring the code, and after making a part
On Thu, Aug 25, 2005 at 01:35:04PM -0400, Bill Mill wrote:
> On 8/25/05, Erik Max Francis <[EMAIL PROTECTED]> wrote:
> > Mark Dickinson wrote:
> >
> > > Questions:
> > >
> > > (1) Can anyone else reproduce this behaviour, or is it just some quirk
> > > of my setup?
> > > (2) Any possible expla
Bill Mill wrote:
>
> Pentium M 1.8 GHz Windows 2k. Here's the top of the profile results
> for fast and slow on my machine (these won't look decent except in a
> fixed-width font):
>
>
> Interestingly, the test.py:36 line, which takes 45 seconds (!!) in the
> slow version, does not appear at all
Bill Mill wrote:
> Unlikely; 2 people have confirmed these results already.
>
> I did find, though, that if I remove all print statements from the
> program, the dummy and non-dummy variable versions take indentical
> time. Can others reproduce this?
Yes, it's obviously a real effect given the o
On 8/25/05, Erik Max Francis <[EMAIL PROTECTED]> wrote:
> Mark Dickinson wrote:
>
> > Questions:
> >
> > (1) Can anyone else reproduce this behaviour, or is it just some quirk
> > of my setup?
> > (2) Any possible explanations? Is there some optimization that kicks
> > in at a certain num
On 8/25/05, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> I have a simple 192-line Python script that begins with the line:
>
> dummy0 = 47
>
> The script runs in less than 2.5 seconds. The variable dummy0 is never
> referenced again, directly or indirectly, by the rest of the script.
>
> Here's
Mark Dickinson wrote:
> Questions:
>
> (1) Can anyone else reproduce this behaviour, or is it just some quirk
> of my setup?
> (2) Any possible explanations? Is there some optimization that kicks
> in at a certain number of lines, or at a certain length of
> bytecode?
> (3) If (2), i
On Thu, Aug 25, 2005 at 04:44:24PM +, Mark Dickinson wrote:
> I have a simple 192-line Python script that begins with the line:
>
> dummy0 = 47
>
> The script runs in less than 2.5 seconds. The variable dummy0 is never
> referenced again, directly or indirectly, by the rest of the script.
>
I have a simple 192-line Python script that begins with the line:
dummy0 = 47
The script runs in less than 2.5 seconds. The variable dummy0 is never
referenced again, directly or indirectly, by the rest of the script.
Here's the surprise: if I remove or comment out this first line, the
script t
24 matches
Mail list logo
