Just another site

Thought this was cool: Guido van Rossum – Google+ – Some patterns for fast Python. Know any others? – Avoid…

leave a comment »

Comments: “Guido van Rossum – Google+ – Some patterns for fast Python. Know any others?

– Avoid…”


“str” + “str” is faster than “%s%s” % (s, s) and even ”.join([s, s]) unless you’re working with thousands of strings, though rarely more readable, and it rarely matters unless you’re doing it thousands of times.

RAM (in-process dict) < memcached < disk IO < net IO – a good caching strategy saves lives.

Know your APIs: Disk IO, DB hits, or any network trips are (almost) always more expensive than any calculations you’re doing – getting a thousand records can be quite fast (with modern DBs), but getting one record a thousand times is almost always intolerably slow – so watch your loops!

If you’re crunching numbers, numpy is your friend (and so are its buddies, cython and pypy). If you’re not, none of these tips probably apply to you, unless you have some crazy nano-second scale requirements for your libraries – and if so – Python may not be the best language! All languages are tools, and some tools are better suited to certain tasks than others.

Lastly, readability and maintainability always trumps performance – always – until performance is your only concern. In my experience, that almost never, ever happens. As long as you’re not writing poor-performing code (for instance, hitting a DB in a large loop), you’re going to be fine, until it’s time to profile!

from Hacker News 50:


Written by cwyalpha

十月 15, 2012 在 4:54 上午

发表在 Uncategorized


Fill in your details below or click an icon to log in: 徽标

You are commenting using your account. Log Out /  更改 )

Google+ photo

You are commenting using your Google+ account. Log Out /  更改 )

Twitter picture

You are commenting using your Twitter account. Log Out /  更改 )

Facebook photo

You are commenting using your Facebook account. Log Out /  更改 )


Connecting to %s

%d 博主赞过: