I think this is spot on, and I'd like to add my own thoughts:
1 -
An oft overlooked area where performance matters, is concurrency. It feels like it's taboo talk about performance and concurrency together, and it can be dangerous to mix the two too much, but they do go hand-in-hand to some degree. Take a web app. If you have 10K req, and it takes 500ms to process each request, you'll need 5000 workers (threads, processes, whatever) and some people to have the wait 1 second to get a response. Drop that processing time to 5ms and you not only drop the amount of workers, but also decreases the response time across the board.
2 -
Databases in general, and B-Trees specifically, are a great example of a generalizations. Redis shows us the performance benefit of using more specialized data structures (yes, Redis is in-memory, but the data structure are more important than the fact that its in memory (though the two are closely related)). At an extreme, if you need to list results in order, nothing beats an array.
3 -
The GC doesn't eliminate the need to think about memory. I've seen a number of performance-sensitive applications that failed to utilize a fraction of the 32GB or 64GB of memory that was available. A lot of developers just don't think about memory anymore. (I can't find it, but I remember a popular post that talked about this with respect to iOS' better performance than Android (while having less resources available)).
> I can't find it, but I remember a popular post that talked about this with respect to iOS' better performance than Android (while having less resources available)
This may have been it, and is a great read anyway if it wasn't:
Concurrency is also a problem if you access or lock resources blindly. I once sped up a Java webapp by factor 10 by removing an unnecessary lock in the authentication and authorization code.
Performance problems aren't always tied to CPU usage. Waiting for disk IO is the most common example, but, as you say, coarse locks can also be problematic. Probably the worst I've seen are threaded web frameworks used for making external API calls (to facebook, say). You can a machine doing 0 CPU and Disk, but completely locking up.
> Probably the worst I've seen are threaded web frameworks used for making external API calls (to facebook, say). You can a machine doing 0 CPU and Disk, but completely locking up.
Or the intranet equivalent: LDAP group resolution for a user. So slow ... so incredibly slow. I've never seen an application which cannot be (massively) speed up by caching this information after retrieving it the first time.
1 - An oft overlooked area where performance matters, is concurrency. It feels like it's taboo talk about performance and concurrency together, and it can be dangerous to mix the two too much, but they do go hand-in-hand to some degree. Take a web app. If you have 10K req, and it takes 500ms to process each request, you'll need 5000 workers (threads, processes, whatever) and some people to have the wait 1 second to get a response. Drop that processing time to 5ms and you not only drop the amount of workers, but also decreases the response time across the board.
2 - Databases in general, and B-Trees specifically, are a great example of a generalizations. Redis shows us the performance benefit of using more specialized data structures (yes, Redis is in-memory, but the data structure are more important than the fact that its in memory (though the two are closely related)). At an extreme, if you need to list results in order, nothing beats an array.
3 - The GC doesn't eliminate the need to think about memory. I've seen a number of performance-sensitive applications that failed to utilize a fraction of the 32GB or 64GB of memory that was available. A lot of developers just don't think about memory anymore. (I can't find it, but I remember a popular post that talked about this with respect to iOS' better performance than Android (while having less resources available)).