alt Hacker NewsI like the priorities.
I think a core thing that's missing is that code that performs well is (IME) also the simplest version of the thing. By that, I mean you'll be;
- Avoiding virtual/dynamic dispatch
- Moving what you can up to compile time
- Setting limits on sizing (e.g. if you know that you only need to handle N requests, you can allocate the right size at start up rather than dynamically sizing)
Realistically for a GC language these points are irrelevant w.r.t. performance, but by following them you'll still end up with a simpler application than one that has no constraints and hides everything behind a runtime-resolved interface.
I generally don't worry too much about static vs dynamic dispatch. Not that I use a lot of interfaces all over the place, but there are certain places where I do (for instance persistence layer abstraction - where it doesn't actually matter since any overhead caused by that is many orders of magnitude smaller than the cost of what the call does anyway)
Also, if someone can understand the code, they can optimize it if needed. So in a way, trying to express oneself clearly and simply can be a way to help optimization later.