For the list append, is it because of the use of len()? Just checked the code because I wanted to know why this is happening. Couldn't figure out the dictionary though.
Both are actually the same effect. When you call data.get(...), you're calling the method, of course, but also looking up the method in the data object's internal dictionary, called __dict__. What the above article is showing is that there's some savings to be made if you cache the lookup.
He's not optimizing a list at all, but he is optimizing a dict - in both cases.
Because data[num] = ... is actually data.set(num, ...), there's another candidate for optimization there, as well - but by now you can probably guess what it is.
Thanks for sharing. I wonder though if this reduces code readability. If we are not talking about mission critical paths, then it may not worth the 10-15 % reduction.
Excellent! You took the time to verify what I was saying without giving proof - and you we right to do so!
The problem is that the last line in the second function is actually building a list.
Here's a better example:
defis_even(x):returnx%2==0@timeitdeffunc1(my_list):""" calling append() in a loop """my_other_list=[]forxinmy_list:ifis_even(x):my_other_list.append(x)func1(list(range(1,9999999)))@timeitdeffunc2(my_list):"""Saving one 'op' by not looking up the is_even function every time """my_other_list=[]func=is_evenforxinmy_list:iffunc(x):my_other_list.append(x)func2(list(range(1,9999999)))@timeitdeffunc3(my_list):"""Using list comprehensions """my_other_list=[xforxinmy_listifis_even(x)]func3(list(range(1,9999999)))
This makes me thing of how slow really Python must be if the evaluation takes so long... Anyone got more info that, how much that affects performance and why?
Great article! Check out the dis module and disassemble the code and it explains why this happens. TLDR: it's one less instruction inside the hot loop.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Wow thanks! I had no idea this was even possible.
For the list
append, is it because of the use oflen()? Just checked the code because I wanted to know why this is happening. Couldn't figure out the dictionary though.Both are actually the same effect. When you call
data.get(...), you're calling the method, of course, but also looking up the method in thedataobject's internal dictionary, called__dict__. What the above article is showing is that there's some savings to be made if you cache the lookup.He's not optimizing a list at all, but he is optimizing a dict - in both cases.
Because
data[num] = ...is actuallydata.set(num, ...), there's another candidate for optimization there, as well - but by now you can probably guess what it is.It's was fixed in python3.8
so v3.8 is faster? (like the article says)
Do you have some source on this? How it was fixed?
Thanks for sharing.
I wonder though if this reduces code readability.
If we are not talking about mission critical paths, then it may not worth the 10-15 % reduction.
Yes it does - idiomatic Python code is typically not written this way.
This. Before applying this technique, make sure to measure the performance of your entire application!
Finally, a better advice for beginners (in my opinion), is to advise them to use comprehensions when they can:
is more idiomatic and even faster than the technique presented here.
@Dimitri Did you tried this -
Kindly Look at the result below -
and as you said -
Excellent! You took the time to verify what I was saying without giving proof - and you we right to do so!
The problem is that the last line in the second function is actually building a list.
Here's a better example:
This makes me thing of how slow really Python must be if the evaluation takes so long... Anyone got more info that, how much that affects performance and why?
Great article!
Check out the dis module and disassemble the code and it explains why this happens. TLDR: it's one less instruction inside the hot loop.