Performance has to be a consideration in technology and architectural choices over the entire life cycle of a project. Despite the common incantation that it’s just something that you can refine after running a profile nearing release, that seldom pays off. Instead you end up with a project that suffers a gruesome death by a million cuts.
This is the story that has played out across countless project life-cycles: deferring any performance discussion as a so-called premature optimization, to the point that you have a solution that is effectively worthless.
And while the endless progress of CPUs could once be counted on to bring relief, single-core speeds have barely increased in years. Quite the opposite, the dominant direction now is for weaker, slower cores that use less power, from that generating less heat and supporting more density.
Standards have changed. Users won’t bear the egregious inefficiencies of web applications from years ago: Multi-second transition and load times are completely unacceptable, and lead to a quick click of the back button. There is a strong correlation between extremely responsive applications and both adoption and perception of quality.
I would posit that one of the reasons native apps have become so dominant on mobile is that the team developing the native app simply had more of a focus on performance as an expectation of the platform, where too many developers in the web domain still hold onto the notion that performance doesn’t matter.
Add that native apps often feature incremental updates, giving the perception of speed and progress, where web apps often use the “generate a whole complex bundle of HTML luggage and serve it up wholesale”. Waiting three seconds for something to happen while components fill in and transitions happen is significantly more palatable than clicking a button and having a seemingly non-responsive platform for the same amount of time. Even if the total time is the same, the former will feel much faster, which is a trick that Apple uses to great success.
Talk about platform performance and invariably you’ll get retorts that are some variation of “You think you’re Facebook or Google?”, conflating scalability with raw, single-user performance: Two entirely different things. But even when you’re talking about scalability, being able to serve 1000 active users on one host economically beats requiring six boxen to do the same. It’s the difference between the app falling over and dying under any significant load at all (the story of almost all web apps dotting the landscape), or taking advantage of that opportunity window.
When you have fundamental performance, not only does it open up economic and deployment opportunities, it gives you more options when it comes to functionality. The site choking to generate a recent items list isn’t going to be first in line when it comes to offering dynamic, powerful, but demanding new functionality like automatic or delta updates.
To segue to a social side project I recently started work on, both selfishly — because I want to see this become a thing in my area, making connections and sharing a garden bounty — and because it enhances national food security, is an open source harvest sharing platform1 — a social and content system for residents in an area to detail their growing plan for the year, to share tips and comments and suggestions, to document their process and progress, and to set up “trades” with other growers (e.g. broccoli for lemon grass, heirloom tomatoes for chicken eggs, etc). The goal being to increase regional engagement, and to provides motives and social rewards for people to make use of their land.
Theoretically such a platform could awkwardly be layered on WordPress, or operated as a ragtag collection of Facebook groups, but neither would provide the necessary tools or community “ownership” of the platform.
I’m open minded when it comes to technology — I’ve used enough tools and technologies that I’ve grown out of the need to treat everything as a nail to my hammer — so given that this is an open source project I assessed every criteria that would make it a success.
I love Go, for instance, but while it would offer the necessary performance, it isn’t broadly used enough to support the potential developer community. Nor does it have the modular attributes necessary for a content system like this.
I love C# and .NET, but it remains largely a Windows affair. If you’re working on a Microsoft stack, it can be a fantastic choice, but if devs work across platforms, and you want to deploy across platforms, solutions like mono are a poor performance, half measure. EDIT (2014-11-12) – Microsoft made a Community Edition of Visual Studio — a full-featured, powerful, fantastic development tool suite — completely free for many users and many cases, and that is a huge step in making C# and .NET a reasonable choice for a project like this.
C++….heh. One of my favorite languages of all, but of course it is woefully ill equipped for such a shared project. For a self-contained, single-developer solution, along with a library like cpoll_cppsp, it would be a credible choice, but not for an open source project.
PHP…there are a lot of PHP developers, and solutions like HHVM make it credible performance wise, but I’ve dealt with PHP enough to absolutely despise it. While I marvel at the wonderful solutions and wins PHP has been a part of (many of the most significant platforms of the web happened via PHP), I hold too much contempt for it.
Ruby…Ruby comes at considerable performance overhead (it is fundamentally a slow platform), the benefit purportedly being that it solves a problem that is not the contemporary problem of web applications anymore: An ideal modern web application for most uses now uses client rendering (via frameworks like backbone, ember, angular, and custom similes), the server-side serving up static resources and dynamic web services. The various benefits of Ruby wash out when you approach the problem this way. Indeed, this client consumption and presentation of fundamental data has completely changed the web industry, rendering every solution like ASP.NET MVC, Struts, and so on, a great solution for a no-longer problem. That server->client friction has always been one of the greatest issues with web development, especially if you then need to build a wholly separate web service platform to serve alternative platforms like native apps.
In the end I decided on an old platform enemy: Java. Notorious once for performance issues — both as an artifact of a grossly inefficient Applet platform that maligned the brand, along with idiomatic implementation patterns that essentially did everything possible to sabotage performance, Java now represents one of the highest performance platforms you can choose. Years of JVM improvements, the evolution of garbage collection, and things like escape analysis and lock elision, have made it the platform that sits under a lot of extremely high performance systems.
A quick prototype of an app built in Netbeans, using JAX-RS web services, running on the Wildfly server, had complex, hierarchical, data-driven web service data bundles (in JSON, a format that incredibly still lacks any type of date or datetime standard, yet the community treats this as a general non-issue) returning — without caching — in less than one millisecond, running on a virtual machine on a run-of-the-mill host. This same host could successfully serve 75,000 data requests per second (again, with no caching), with nary an error and a still acceptable average response time.
The result of this sort of performance is that this solution could be hosted on a miserable machine and still robustly serve fairly significant loads. That there is enough performance on any reasonable platform that the feature set is unbounded and open — derelict antiques like “hit F5 to refresh” tossed aside, for instance.
It isn’t my platform love, but the features of the language (particularly for a modular project), the performance of the platform in practice, and the ubiquity of its support made it my choice for this project.
1 – I am unaware of any similar project, however this is exactly the sort of project that makes for delicious startup gravy for the mainstream media. Put a weaved basket full of produce in front of some nerdy looking sorts around a hip looking table, in a minimalist office with beachwood floors, large glass windows in an open-concept office, a shiny looking expresso machine and selection of bagels placed carefully in the background…startup gold, Jerry. Gold! “These Hackers Are Looking to Change the Way We Eat” shouts the headline.