4 ms·

This is so important: Do not even try to write what you think is effective code before benchmarking. The VM has many clever optimizations. And even if

by struppi 11y ago

This is so important: Do not even try to write what you think is effective code before benchmarking. The VM has many clever optimizations. And even if you will somehow learn of all of them, in the next release they still can be changed. Instead, write a simple and clean piece of code, make a benchmark, find the real bottleneck and rewrite code in small parts. Every now and then I see some strange code at a client I work with, and the justification is "Performance". Because somebody thought it might be faster - But they didn't check it back then. And they don't have an automated performance test that continuosly validates if their "dirty but fast" code is still faster than the clean version... Don't even ask how many hours of developer time I saw wasted because of "dirty but fast" code. Where the code often was not much faster then the clean version. Or it was faster, but speed was not crucial in the area where the code operated. Also, I guess a lot of the optimizations from old blog posts or the first "Effective Java" will not yield amazing results anymore, as compilers and runtimes are getting better. I also like this one: Do not think that programming in C++ or any other lower-level language is a must for having good performance. Good architecture, benchmarking and profiling are far more important. But I don't think it is as clear-cut as the author writes it. For some problems, having total control over your memory layout and what gets exectued when (i.e. C or C++ or ...) can lead to huge benefits. And sometimes, the runtime is just more clever optimizing the code than you are.

masklinn 11y ago
> This is so important: [benchmark] As any follower of @mraleph (http://mrale.ph http://mrale.ph / https://twitter.com/mraleph https://twitter.com/mraleph) is aware, it's very easy to benchmark the wrong thing (or benchmark more or less nothing), or to write an isolated benchmark which doesn't reflect real-world use.
pjc50 11y ago
There's one thing you can do without benchmarking: approximate complexity (O(n)) analysis. You need to be sensible about what N is though: even O(n^3) isn't too bad if it's an operation on a user-displayed list of half a dozen items. With a bit of thought this even leads to cleaner code: do you really need to pass a large chunk of data around when you only need a particular precalculated quantity? But generally benchmarking and applying Amdahl's law is the way to go. First identify which part of the system is slow!
- deleted 11y ago
  [deleted]
  - losvedir 11y ago
    Have you not used redis? Every command[0] begins its documentation with its time complexity. [0]http://redis.io/commands http://redis.io/commands

by struppi 11y ago

masklinn 11y ago

> This is so important: [benchmark] As any follower of @mraleph (http://mrale.ph http://mrale.ph / https://twitter.com/mraleph https://twitter.com/mraleph) is aware, it's very easy to benchmark the wrong thing (or benchmark more or less nothing), or to write an isolated benchmark which doesn't reflect real-world use.

pjc50 11y ago

There's one thing you can do without benchmarking: approximate complexity (O(n)) analysis. You need to be sensible about what N is though: even O(n^3) isn't too bad if it's an operation on a user-displayed list of half a dozen items. With a bit of thought this even leads to cleaner code: do you really need to pass a large chunk of data around when you only need a particular precalculated quantity? But generally benchmarking and applying Amdahl's law is the way to go. First identify which part of the system is slow!

deleted 11y ago
[deleted]
- losvedir 11y ago
  Have you not used redis? Every command[0] begins its documentation with its time complexity. [0]http://redis.io/commands http://redis.io/commands