addressalign-toparrow-leftarrow-leftarrow-right-10x10arrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcredit-cardcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobe--smallglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1languagelaunch-new-window--smalllight-bulblightning-boltlinklocation-pinlockm-swarmSearchmailmediummessagesminusmobilemoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstar-shapestartickettrashtriangle-downtriangle-uptwitteruserwarningyahooyoutube

Re: [python-189] Python performance anti-patterns

From: John W.
Sent on: Thursday, January 10, 2013, 4:12 PM
How about overuse of dicts as data structures?  Dict ease of use (a really nice thing about Python) can lead to abuse.

There are times when accessing a dict's dict's dict's dict, e.g. navdata['drone']['camera']['translation']['x'] might make sense, but there are times where it feels like a shortcut and I'd like real objects (or at least namedtuples) with the benefits that offers: works with static analysis, better documented/more readable.


On Thu, Jan 10, 2013 at 4:05 PM, Simeon Franklin <[address removed]> wrote:
On Thu, Jan 10, 2013 at 12:34 PM, Alex Gaynor <[address removed]> wrote:
I really cannot imagine anything less import than dict() vs. {}:

I agree with you (and Brendan and Glyph) - I really try to use the language features that make the most sense from a readability perspective. I'm not looking for micro-optimizations here and it sounds like the answer to my question (so far) is a resounding "no".

The example I mentioned (that no longer applies) was worth avoiding. In older versions of Python doing the naively straightforward thing (+= to accumulate a string) could be orders of magnitude slower than appending to an array and then .joining the array on an empty string separator. See eg http://www.skymind.com/~ocrow/python_string/ from circa 2004. All the advice so far is good general advice - profile, use the right data structures, use PyPy - but none of it answers my question directly. In this case a negative result is a good one - I'm happy not to have to mangle my code to avoid "gotchas" in the language*.

-regards
Simeon Franklin

* Actually the one other "gotcha" I've considered is that due to the GIL threads are not as useful as they are in some other languages to deal with performance problems... But that approaches more the "choose the right algorithms and data structures" level of knowledge.




--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Simeon Franklin ([address removed]) from San Francisco Python Meetup Group.
To learn more about Simeon Franklin, visit his/her member profile

People in this
group are also in: