En Tue, 26 Feb 2008 12:33:01 -0200, <[EMAIL PROTECTED]> escribió:
> On Feb 26, 8:14 am, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
>> I guess it's the method lookup that's the slow part. Factor it out of
>> the
>> loop and measure again::
>>
>> adict_get = adict.get
>> for _ in
[EMAIL PROTECTED] napisał(a):
> [EMAIL PROTECTED]:
> > As for the original prooblem, why not use
> > defaultdict? I think it's the most idiomatic way to achieve what we
> > want. And also the fastest one, according to my quick-and-dirty tests:
>
> It adds the new keys, I can't accept that:
Right,
[EMAIL PROTECTED]:
> As for the original prooblem, why not use
> defaultdict? I think it's the most idiomatic way to achieve what we
> want. And also the fastest one, according to my quick-and-dirty tests:
It adds the new keys, I can't accept that:
>>> from collections import defaultdict as dd
>>
[EMAIL PROTECTED] napisał(a):
> It's slower still, despite doing the lookup two times half of the
> times (half keys are present in the test set). The "in" is an
> operator, it's faster than a method call, but I don't understand the
> other details. Now the difference between 1.78 and 1.56 is small
On Feb 26, 8:40 am, [EMAIL PROTECTED] wrote:
> Marc 'BlackJack' Rintsch:
>
> > I guess it's the method lookup that's the slow part. Factor it out of the
> > loop and measure again::
>
> I did know of that optimization, but sometimes I "forget" about it...
> The new timings:
>
> Output timings, bes
Marc 'BlackJack' Rintsch:
> I guess it's the method lookup that's the slow part. Factor it out of the
> loop and measure again::
I did know of that optimization, but sometimes I "forget" about it...
The new timings:
Output timings, best of 3, unloaded CPU:
2.32 s with adict.get
1.56 s with "in"
On Tue, 26 Feb 2008 06:33:01 -0800, castironpi wrote:
> On Feb 26, 8:14 am, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
>> On Tue, 26 Feb 2008 06:02:12 -0800, bearophileHUGS wrote:
>> > This is a real difference, that has real impact on the programs I
>> > write, so I often use the if/else
On Feb 26, 8:14 am, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
> On Tue, 26 Feb 2008 06:02:12 -0800, bearophileHUGS wrote:
> > This is a real difference, that has real impact on the programs I
> > write, so I often use the if/else approach, despite the dict.get()
> > method being semantica
Marc 'BlackJack' Rintsch wrote:
> On Tue, 26 Feb 2008 06:02:12 -0800, bearophileHUGS wrote:
>
>> This is a real difference, that has real impact on the programs I
>> write, so I often use the if/else approach, despite the dict.get()
>> method being semantically fitter and shorter.
>> So can the di
On Tue, 26 Feb 2008 06:02:12 -0800, bearophileHUGS wrote:
> This is a real difference, that has real impact on the programs I
> write, so I often use the if/else approach, despite the dict.get()
> method being semantically fitter and shorter.
> So can the dict.get() method be speed up? And if not,
When I use dictionaries I find the dict.get() method very handy, and
I'd like to use it often, but I think it's quite slow. This is a small
benchmark:
from random import randrange
from timeit import default_timer as clock
def main(N, M):
keys = list(set(randrange(2*N) for n in xrange(N)))
11 matches
Mail list logo
