Python.org - Performance tips page - Avoiding dots section - Question
Hi, I have read the part about "Avoiding dots <https://wiki.python.org/moin/PythonSpeed/PerformanceTips#Avoiding_dots...>" on the python.org Performance tips web page. Even if I understand the concept, I wanted to check the example and ran the attached program. It shows the "optimized" example to be slower than the non-optimized one. Who could I discuss that issue with? Thank you very much Regards Sébastien Aubry
On Fri, Dec 2, 2016 at 10:29 PM, Sébastien Aubry <sebastien.aubry31@gmail.com> wrote:
I have read the part about "Avoiding dots" on the python.org Performance tips web page.
Even if I understand the concept, I wanted to check the example and ran the attached program. It shows the "optimized" example to be slower than the non-optimized one.
Who could I discuss that issue with?
Best would be to start a discussion on the main python-list@python.org mailing list. There is a LOT to discover about optimization and timing, and very few of us are experts, but most of us know how very inexpert we are :) ChrisA
On Fri, Dec 2, 2016 at 11:31 AM, Chris Angelico <rosuav@gmail.com> wrote:
Best would be to start a discussion on the main python-list@python.org mailing list. There is a LOT to discover about optimization and timing, and very few of us are experts, but most of us know how very inexpert we are :)
Also, remember that premature optimization is the root of all evil in programming! The kind of gains to be expected by hoisting attribute lookups out of the loop will usually be lost in the noise compared with gains to be made from use of superior algorithms (often involving refactoring inappropriate data structures). In the particular code you submitted I saw that the "optimized" version is about 10% slower than the "non-optimzed" version. Until you get your algorithm correct, it's hardly worth worrying about. After all, the Pythonic way to create the value you want is simply "WORD" * 100000 Here's the output from an updated program where the third function simply computes that expression: python3 /tmp/times.py 2.358054072014056 2.167076243989868 0.002145289006875828 It seems to me that proves the point exactly: focus on efficient algorithms! I understand you may simply be exploring python's behaviour, which is great, but as far as production work goes, the old saw is true: "First, make your program work; then, if it doesn't work fast enough, make it work faster" regards Steve Steve Holden
Hi, I have updated my example, so that it exactly matches the website. Now it is Ok. I don't see what was wrong in my first example. Regards Sébastien
Hi, Thank you for your replies.
I fully understand your point, Steve, and agree with it, but I just wanted to check if one should really "Avoid dots" as suggested on the Python website itself. I wonder if this section should not be removed, since the given example itself is wrong (I mean slower). I will post this message on the mailing list,
Regards
2016-12-02 13:14 GMT+01:00 Steve Holden <steve@holdenweb.com>:
On Fri, Dec 2, 2016 at 11:31 AM, Chris Angelico <rosuav@gmail.com> wrote:
Best would be to start a discussion on the main python-list@python.org mailing list. There is a LOT to discover about optimization and timing, and very few of us are experts, but most of us know how very inexpert we are :)
Also, remember that premature optimization is the root of all evil in programming! The kind of gains to be expected by hoisting attribute lookups out of the loop will usually be lost in the noise compared with gains to be made from use of superior algorithms (often involving refactoring inappropriate data structures).
In the particular code you submitted I saw that the "optimized" version is about 10% slower than the "non-optimzed" version. Until you get your algorithm correct, it's hardly worth worrying about. After all, the Pythonic way to create the value you want is simply
"WORD" * 100000
Here's the output from an updated program where the third function simply computes that expression:
python3 /tmp/times.py 2.358054072014056 2.167076243989868 0.002145289006875828
It seems to me that proves the point exactly: focus on efficient algorithms!
I understand you may simply be exploring python's behaviour, which is great, but as far as production work goes, the old saw is true:
"First, make your program work; then, if it doesn't work fast enough, make it work faster"
regards Steve
Steve Holden
participants (3)
-
Chris Angelico -
Steve Holden -
Sébastien Aubry