3 ms·

There's such a thing as being penny-wise and pound-foolish, though. Imagine if I told you I had a desktop application that was slow, and I'd achieved a 2-4x sp

There's such a thing as being penny-wise and pound-foolish, though. Imagine if I told you I had a desktop application that was slow, and I'd achieved a 2-4x speedup in common tasks by rewriting the whole thing in a different language. But then you discovered that I'd written it in such a way that it had to hit the (spinning-platters, just to drive the analogy home) disk to do even the most basic things. You would, I hope, tell me that I'd wasted a ton of effort optimizing entirely the wrong thing, and that my 2-4x speedup from choosing a new language would be blown away by the likely multiple-orders-of-magnitude speedups I could get from better memory management and I/O patterns. In the web world, most discussion of backend languages is like this. Sure, you could get your impressive-sounding speedup from switching to a "faster" language. But the time spent executing application code is so utterly dwarfed by the time you spend idle while waiting on a database, or by the time it takes to send things over the network to the client, that "switch to a faster application language" should probably be the 1000th item on the list of the first 1000 things you do to try to improve performance.

bluGill 9y ago
Maybe, maybe not. What does the profiler say. This is always the first question in optimization, if the profiler comes up with anything you can fix, that fix is always your biggest bang for your buck. If the profiler doesn't really say anything we are in a tough spot. There are things that are worth doing anyway, you have to be careful, in most cases even if the change is really faster it probably will not be fast enough. Back to your example, maybe we cannot fix the database, but even if the database query is 10 seconds, going from 10.5 seconds to 10.001 seconds response is an improvement. Your scale is an important question. Facebook can save tens of thousands per month with an optimization so small no user will notice it - between not having to buy as many servers, and not having to pay as much power to run the CPU for those extra cycles. (Facebook will not give you the actual numbers, but they can tell you they have measured and you can read between the lines to guess how much it must be given they have a few people employed in small optimizations)
- ubernostrum 9y ago
  In web apps, the first thing you do is start looking at DB queries. How many, how complex, etc. Reducing the number of queries and making those queries as simple/fast as possible accounts for at least the first quarter of my hypothetical "first 1000 things you do to try to improve performance" list. Also, regarding scale: the number of entities operating at AmaFaceGoog scale is small. The number of entities operating even within an order of magnitude or two of them is small. The odds are very much against any advice relevant only at that scale being relevant to the average Hacker News reader.
nostrademons 9y ago
The idea that a webapp should be a frontend to a RDBMS is itself an artifact of the "time to market is way more important than computational efficiency" culture of the mid-00s. You can get 1000x speedups by ditching the database and serving out of RAM. Sites like Hacker News, PlentyOfFish, Mailinator and Google (back when the webserver was written by just Craig Silverstein rather than a team of hundreds) serve thousands of queries per second off a single box. In most cases the actual access patterns of apps don't map particularly well to either an RDBMS or a key-value store, so if you're willing to put in the time to develop a custom datastore, there are still large efficiencies available.

bluGill 9y ago

Maybe, maybe not. What does the profiler say. This is always the first question in optimization, if the profiler comes up with anything you can fix, that fix is always your biggest bang for your buck. If the profiler doesn't really say anything we are in a tough spot. There are things that are worth doing anyway, you have to be careful, in most cases even if the change is really faster it probably will not be fast enough. Back to your example, maybe we cannot fix the database, but even if the database query is 10 seconds, going from 10.5 seconds to 10.001 seconds response is an improvement. Your scale is an important question. Facebook can save tens of thousands per month with an optimization so small no user will notice it - between not having to buy as many servers, and not having to pay as much power to run the CPU for those extra cycles. (Facebook will not give you the actual numbers, but they can tell you they have measured and you can read between the lines to guess how much it must be given they have a few people employed in small optimizations)

ubernostrum 9y ago
In web apps, the first thing you do is start looking at DB queries. How many, how complex, etc. Reducing the number of queries and making those queries as simple/fast as possible accounts for at least the first quarter of my hypothetical "first 1000 things you do to try to improve performance" list. Also, regarding scale: the number of entities operating at AmaFaceGoog scale is small. The number of entities operating even within an order of magnitude or two of them is small. The odds are very much against any advice relevant only at that scale being relevant to the average Hacker News reader.

nostrademons 9y ago

The idea that a webapp should be a frontend to a RDBMS is itself an artifact of the "time to market is way more important than computational efficiency" culture of the mid-00s. You can get 1000x speedups by ditching the database and serving out of RAM. Sites like Hacker News, PlentyOfFish, Mailinator and Google (back when the webserver was written by just Craig Silverstein rather than a team of hundreds) serve thousands of queries per second off a single box. In most cases the actual access patterns of apps don't map particularly well to either an RDBMS or a key-value store, so if you're willing to put in the time to develop a custom datastore, there are still large efficiencies available.