6 ms·
Perhaps a better understood paraphrase: Never guess at performance, and don’t measure for performance until the application works.
by throwaway0asd 4y ago
Perhaps a better understood paraphrase: Never guess at performance, and don’t measure for performance until the application works.
- djmips 4y ago1st part. YES. 2nd part. NO. If your end goal needs to meet a certain mark then you need to be measuring as you go. If you are headed down the wrong path, by not paying attention to perf you'll end up bogged down rewriting systems that 'work' but they were never going to be fast enough. I've been through this headache too many times now to not get a little irritated when projects don't keep perf and memory usage on the same importance as 'working'. This often manifest by developing on much more powerful hardware than will be shipped on... All you need is the measure part. Then you won't do the evil thing of optimizing something that makes it more brittle and hard to maintain etc.
- s1k3 4y agoWell it’s not like you don’t keep it in mind. Your project has some baseline performance need and you should be building with the common practices and paradigms you used to build the other parts. The point is, don’t try to guess which part might need optimization tweaks. Write it first and then prove you need to spend extra time improving something.
- djmips 4y agoBut don't write it all first, that is don't wait until your shipping. I mean if you are trying to be first to market maybe that changes things. Everyone's developing different things in different markets but in my experience developers tend to hold onto that particular mantra, and it turns into wait until the last minute to actually check perf. See other comment about the immaturity of the industry which I agree with.
- throwaway0asd 4y agoI agree in theory but not in practice. Most developers have no idea how to measure the performance of a software product either in code units, libraries, features, or the product as a whole. Worse, they really have no idea what to measure. This is even after you’ve passed that tremendous hurdle that you need measurements not assumptions. A large part of that is due to the immaturity of software as a profession relative to other professions. Measuring things takes tremendous effort and many developers don’t want to challenge their deeply held assumptions of how things work. Often when you present performance measures to developers they will invent an excuse to throw the data out if they don’t like the conclusion.
- ncmncm 4y agoIf performance matters, you hire the subset of programmers who do have an idea about performance, and who even get it right before measuring.
- djmips 4y agoSigh, this is true. Better training and better tools can help make obvious their mistakes but I don't know how to combat the dogma. I've often been shocked how almost superstitious developers are - you'd think developers would have a more scientific approach but they are just as likely to chase after ghosts than optimize what needs to be optimized.
- peteradio 4y agoWrap a timer around your tests, there that is measuring something!
- switchbak 4y agoSo 90% of programming is crap? (Sturgeon's law) Seriously though, there are plenty of developers who can cautiously evaluate performance as they go. It's just that it's not a super common skill (nor is writing low level code, etc), but it exists and is happening all the time. Game devs for example.