Oh! And as far as I understand they're equally memory consuming
import sys
from collections import namedtuple
T = namedtuple('T', 'a b c d e')
assert sys.getsizeof((1,2,3,4,5)) == sys.getsizeof(T(1,2,3,4,5))
W dniu niedziela, 23 lutego 2014 14:12:38 UTC+1 użytkownik Adam Kaliński
napisał:
>
> I did my own tests with similar results:
>
> http://nbviewer.ipython.org/gist/adamkal/9171081
>
> looks like creating a namedtuple is also quite time consuming and it's
> even hard to compare to tuple here.
> Good thing is that we have backward compatibility that has no overhead on
> accessing data.
>
>
> W dniu sobota, 22 lutego 2014 19:01:21 UTC+1 użytkownik Stratos Moros
> napisał:
>>
>> Completely unscientific microbenchmarks:
>> (gist<https://gist.github.com/stratoukos/dcde41ee0903dcdd577a>
>> )
>>
>> >>> from timeit import Timer
>>
>> ## creation
>> # tuple
>> >>> Timer('(1, 2, 3, 4, 5)').timeit()
>> 0.02694106101989746
>>
>> # namedtuple with args
>> >>> Timer('T(1, 2, 3, 4, 5)', setup='''
>> from collections import namedtuple
>> T = namedtuple("T", "a b c d e")'''
>> ).timeit()
>> 0.773979902267456
>>
>> # namedtuple with kwargs
>> >>> Timer('T(a=1, b=2, c=3, d=4, e=5)', setup='''
>> from collections import namedtuple
>> T = namedtuple("T", "a b c d e")'''
>> ).timeit()
>> 1.155663013458252
>>
>> ## item access
>> # tuple
>> >>> Timer('t[0], t[1], t[2], t[3], t[4]', setup='t = (1, 2, 3, 4,
>> >>> 5)').timeit()
>> 0.3240630626678467
>>
>> # namedtuple with indices
>> >>> Timer('t[0], t[1], t[2], t[3], t[4]', setup='''
>> from collections import namedtuple
>> T = namedtuple("T", "a b c d e")
>> t = T(1, 2, 3, 4, 5)'''
>> ).timeit()
>> 0.2994410991668701
>>
>> # namedtuple with attributes
>> >>> Timer('t.a, t.b, t.c, t.d, t.e', setup='''
>> from collections import namedtuple
>> T = namedtuple("T", "a b c d e")
>> t = T(1, 2, 3, 4, 5)'''
>> ).timeit()
>> 0.9363529682159424
>>
>> It seems that the only significant slowdown is on a namedtuple's
>> creation. I imagine the impact would be negligible on a complete
>> request-response cycle, but that would have to be tested.
>>
>> Accessing a namedtuple's items using attributes is also somewhat slower,
>> but this wouldn't be a problem. Existing code would continue to work with
>> the same performance and users could decide for themselves which way to
>> access a namedtuple's items for new code.
>>
>> On 22 Feb 2014, at 18:37, Florian Apolloner wrote:
>>
>> On Saturday, February 22, 2014 5:24:39 PM UTC+1, Adam Kaliński wrote:
>>
>> What do you guys think?
>>
>> Sounds good, you might check if namedtuple has negative performance
>> effects
>> (I doubt it, but who knows). The reason we didn't add it yet is that it
>> just exists since 2.6.
>>
>> cheers,
>> Florian
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To post to this group, send email to [email protected].
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/61b1a5f0-1d1c-480d-87cd-639c728327a7%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/72ff4c73-0ca9-415c-b742-a1f240e9e659%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
