Live data from Hacker News

Django plugins you shouldn't start without

blog.hndigest.com

11–20 of 89 posts

Re: Django plugins you shouldn't start without

#11

As someone who is just starting to dive into Django and Python in general I have to admit being confused by benchmark after benchmark that puts Python near to the bottom of the performance curve when compared to other technologies (Go being one that jumps out at me). I have to admit that part of me is wondering if I am making the right decision in investing time, effort and money getting up to speed on Python/Django…

I wouldn't take random benchmarks on someone's blog particularly seriously. There are many different performance metrics and many different ways to configure your web server and database. Most of the time these things are IO bound in these types of applications. Ultimately it depends on your particular application (which will probably be a little different from "hello world" and so will have a different performance profile). That said, it's not particularly surprising the Go would go faster for most equivalent (the concept of equivalence between programs in different languages is a tricky on itself) programs given it is compiled ahead of time and has complete type information about programs. I would remain a little dubious about the whether the benchmarks involving PHP were really comparing like with like.

My advice is not to sweat it and know that if/when the time comes that there are plenty of options for making things fast such as load balancers, serving static files from another machine, database on a different machine, various kinds of caching (whole page, database level or somewhere in between), tweaking the number of python threads/processes, etc and that you can choose these based on the results of benchmarks. A lot of the time there are big wins to be found in optimising frontend stuff first anyway.

Re: Django plugins you shouldn't start without

#12

As someone who is just starting to dive into Django and Python in general I have to admit being confused by benchmark after benchmark that puts Python near to the bottom of the performance curve when compared to other technologies (Go being one that jumps out at me). I have to admit that part of me is wondering if I am making the right decision in investing time, effort and money getting up to speed on Python/Django…

Those benchmarks are for CPU-bound tasks. Typical web sites usually have other kinds of bottlenecks.

So, if you're doing heavy calculations in your user interface layer (that's what a web site is) - you're a) supposedly doing something wrong b) probably better with something else than plain CPython.

In many other cases, Python is fine. Not the very best option, performance-wise, but there are many other aspects than performance, too.

Re: Django plugins you shouldn't start without

#13
What, no django-annoying? That's the first thing I ever use:

https://github.com/skorokithakis/django-annoying

That, and shortuuid:

https://pypi.python.org/pypi/shortuuid/

Disclosure: I maintain one and wrote the other, but they and South are the three things I use for every project.

Re: Django plugins you shouldn't start without

#14

As someone who is just starting to dive into Django and Python in general I have to admit being confused by benchmark after benchmark that puts Python near to the bottom of the performance curve when compared to other technologies (Go being one that jumps out at me). I have to admit that part of me is wondering if I am making the right decision in investing time, effort and money getting up to speed on Python/Django…

the perspective is, if you can be 20% more productive in Python vs. Go due to the ecosystem and style of Python, you can spend all the money you save in development costs on a few more servers to offset whatever performance penalties you find. I'm not sure what benchmarks you're looking at, but in the real world Python provides the infrastructure for extremely high volume sites like Reddit, Dropbox, Hulu and a crapload more.

That's not to say runtime performance issues have no effect, for example if you had some kind of algorithmic server at the center of a high frequency trading system or something like that, then benchmarks might be more critical (in which case write that one service in Go or C, then have your Python infrastructure talk to it via REST or as a C extension). It kind of depends on what you're doing but in the vast majority of business cases, it's not.

Pypy is also a great alternative to cPython which I hope starts to become viable for widespread production usage very soon - it features performance a lot more like the JVM.

Re: Django plugins you shouldn't start without

#15
post #6

Excellent. Pile up your django with extensions, then look forward to the fun when you have to port your app from e.g. django 1.3 to 1.5 and find a new set of versions of all of your dependencies that work nicely together. And of course figure out a migration path for it all. That is, if extension xyz is still maintained at all. Lean is beautiful, people. Carefully assess every dependency you add, as each one has the…

Yep

Re: Django plugins you shouldn't start without

#16
post #10

As someone who is just starting to dive into Django and Python in general I have to admit being confused by benchmark after benchmark that puts Python near to the bottom of the performance curve when compared to other technologies (Go being one that jumps out at me). I have to admit that part of me is wondering if I am making the right decision in investing time, effort and money getting up to speed on Python/Django…

For many web programming tasks, your user-perceptible speed and/or maximum system loads will not be dominated by the performance of your web application but rather by database, I/O (including networking), and client performance (JS performance, aggressive asset caching, CDN usage, etc etc). Go or Java are wonderful languages if you have serious number-crunching needs or if cutting your server budget in half would sav…

Plus, Django/Rails pretty much have a library for anything you'll want to write. You can cobble applications together in days, and I've done it multiple times. I tried Go for web development, but I had to reinvent everything, which was just too slow.

Re: Django plugins you shouldn't start without

#17
This seems pretty excessive and I'm not even a purist (does one really need to graph models?). Only Django specific plugins that I rely on are South, django-annoying [1] and djorm-ext-expressions [2] but I couldn't see myself building anything larger without Celery anymore.

[1]: https://bitbucket.org/offline/django-annoying [2]: https://github.com/niwibe/djorm-ext-expressions

Re: Django plugins you shouldn't start without

#18

What, no django-annoying? That's the first thing I ever use: https://github.com/skorokithakis/django-annoying That, and shortuuid: https://pypi.python.org/pypi/shortuuid/ Disclosure: I maintain one and wrote the other, but they and South are the three things I use for every project.

Django-annoying is freaking awesome, I have been using it for couple years now (get_object_or_None and render_to <3). Didn't know that you had taken it over from offline, great job.

Re: Django plugins you shouldn't start without

#19
post #6

Excellent. Pile up your django with extensions, then look forward to the fun when you have to port your app from e.g. django 1.3 to 1.5 and find a new set of versions of all of your dependencies that work nicely together. And of course figure out a migration path for it all. That is, if extension xyz is still maintained at all. Lean is beautiful, people. Carefully assess every dependency you add, as each one has the…

Wait. If you need a piece of functionality, you either get something that works out of the box, or you spend X hours writing it. If the out-of-the-box thing breaks and you spend Y hours fixing it, then Y has to be much greater than X to not be worth it, which, in my experience, it never is.

Not to mention that, if the library broke, then the thing you would have written would have probably broken as well, and you wouldn't have the benefit of a thousand other users who might have had (and fixed) the problem before you. This just smells of FUD to me, as it rarely is a problem to me in practice.

Post reply on HN