Magnetic's real-time bidding system, written in pure Python, needs to keep up with a tremendous volume of incoming requests. On an ordinary weekday, our application handles about 300,000 requests per second at peak volumes, and responds in under 10 milliseconds. It should be obvious that at this scale optimizing the performance of the hottest sections of our code is of utmost importance. This is the story of the evolution of one such hot section over several performance-improving revisions.
A good test suite is a developer's best friend -- it tells you what your code does and what it's supposed to do. It's your second set of eyes as you're working, and your safety net before you go to production.
By contrast, a bad test suite stands in the way of progress -- whenever you make a small change, suddenly fifty tests are failing, and it's not clear how or why the cases are related to your change.
Today I managed to get myself a little bit stuck with Heroku's otherwise seamless Python support. In an earlier revision of my app, I had used
-e to install an editable version of a package (the version of the package I needed had not yet been released to PyPI, so I pointed pip at Github). Since then, the version I need has been released.
git push heroku master, and all is well, right? Not so fast...
Pop quiz: how would you implement Python's
xrange (known in Python 3.x as
range) in Python and without making a list or any other sequence type?
If you answered "with a generator," you'd be wrong! And it's likely because you've only ever used an
xrange in code like:
for i in xrange(10): # do something 10 times
In this case (where the
xrange is only used as an "argument" to a
for loop), a generator would probably suffice. But, in fact,
xrange is implemented as an object, not a function or generator. Why? Let's find out.