5 ms·
I definitely agree on the false dichotomy between performance and readable code. > 1) Most code, i.e. at least 80% of the code in a codebase, will never be a p
by thethirdone 3y ago
I definitely agree on the false dichotomy between performance and readable code.
> 1) Most code, i.e. at least 80% of the code in a codebase, will never be a performance hotspot and does not need specific optimizations (i.e. as long as the code does not do stupidly inefficient things, it's probably good enough).
The hard part is knowing what "stupidly inefficient things" are. If you never do excessive optimization, its easy to drift towards less efficient over time because your baseline for what performance is possible slows down. Knowing how to do performance optimization that is not worth it and knowing what the best level of efficiency to shoot for is the mark of a good engineer.
- jackmott42 3y agoYeah, absent an effort to speed up a code base, it will tend to get slower, unless the team has a culture of performance, everyone is looking for easy performance wins and taking them, and common performance mistakes and getting rid of them. To do that the team needs experience with performance, and most of internet programmer culture is just to lecture people about how programmers are cheaper than hardware if anyone asks or talks about performance. So many people don't get that experience.
- radlad 3y ago> programmers are cheaper than hardware Did you mean the reverse of this, I assume?
- 908B64B197 3y agoDepends on your install base/target. At Apple scale, paying a few performance engineers 1M/y is much cheaper than shipping bibber and more powerful CPU in each iPhone. Same thing for AWS or Azure.
- josephg 3y agoModern macos is pretty unusably slow on old apple hardware. The same hardware ran earlier versions of the OS just fine. I’m not sure what’s going wrong at apple, but I don’t think they have enough performance engineers working on the Mac. I run a CPU monitor in my dash (and have for years). The efficiency cores are very often busy doing some rubbish tasks I didn’t ask for while my computer is idle. Things like reindexing files, or re-scanning my photos for faces or something like that. I’ve started to think of them as the CPU cores apple put in my computer to keep their useless internal projects from ruining their hardware. Linux annoys me regularly, but at least my cores are almost totally idle whenever my hands aren’t on the keyboard.
- nyarlathotep_ 3y agoWindow server pegs CPU on older hardware doing any sort of trackpad gesture etc. Wasn't the case in Mojave and adjacent releases. Big Sur on are noticeably worse than the earlier releases. Disabling animations/transparency saves a bit, but it's still remarkably poor.
- jjav 3y ago> So many people don't get that experience. This is very true. The misuse of the "premature optimization" mantra and the thought that valuable programmer time should never be spent on performance have done a disservice to a generation or two of developers. To the point that so many developers don't even believe performance has any significance and the cloud just magically makes it fast. Spending a week optimizing some function to shave off a few seconds may be totally worth it, just depends how often it runs. If it is a code path being used by millions of people, it can quickly become very valuable. Cost is another factor. Sure you might be able to effortlessly spin up dozens or hundreds more instances on demand to handle the load because the code is so slow one instance can barely handle a few dozen requests per second, but you're paying for that. Make an instance capable of handling a few thousand rps and suddenly you've save very real money. And battery life on all portable devices also benefits from more efficient CPU usage.
- coffeeling 3y agoThe sad part is the cloud means web based UI, and web based UI is rarely fast and lightweight.
- simplotek 3y ago> To do that the team needs experience with performance, and most of internet programmer culture is just to lecture people about how programmers are cheaper than hardware if anyone asks or talks about performance. But this is an absolute truth, isn't it? I mean, what's more important to your business: avoid the need to launch an EC2 instance, or implement that user flow in one day instead of one week? Do you care if it takes 50ms to show your dialog box instead of 40ms? Do you really care if you pass all your objects by value, with a few deep copies, instead of passing everything by reference? The truth of the matter is that in general all performance bottlenecks are caused by software architecture and algorithms, not "clean code" implementations.
- hawk_ 3y ago> Yeah, absent an effort to speed up a code base, it will tend to get slower, unless the team has a culture of performance My experience with JVM over the last few years says otherwise. Most teams I have come across try too hard to achieve "performance" where very simple idiomatic code would have sufficed. Idiomatic code improves in performance every release. Instead they picked up some dogmas based on JVMs of the past and their "peformance culture" is a farce.
- cogman10 3y agoFunnily, what I've seen most frequently with the JVM is most optimizations are on the order of "You should have used a HashSet here, not a List that you keep sorting and removing duplicates from!" The majority of performance issues I've ran into aren't "Oh, I need just the right structure of code to make things go fast" but rather "I used a Map<String, Object> instead of a PoJo, why is my code slow?" I think a big problem is the "don't prematurely optimize" has been taken to mean "never think about how your algorithm will perform". It allows someone to write an n^2 or n^3 algorithm when the n algorithm is just as readable (usually moreso!)
- josephg 3y agoThe problem with all this is that performance optimization is nothing without measurement. How many items are in your list / map in the regular case? Do you know? And if the number is small, how fast does Map go compared to a list with that many elements? Oh this function is slow? How often is it called? If it’s only called once, maybe it’s fine. Performance optimization work should be guided by real data, and knowledge of your users. What features matter the most? Are your users on network constrained devices? Are they running out of disk space? Are GC pauses a problem? What is the normal / maximum size of the input to your software? Without knowing this stuff, you can’t focus your attention on the right things re: performance. You’ll end up spending time and energy making the wrong things fast with marginal benefit.
- GuB-42 3y agoI'd say significantly reducing big-O complexity (ex: N^2 to NlogN) is worth it without measurement. That's because even if it is not significant during your tests doesn't mean it won't be a catastrophe later as N increases, maybe even a vulnerability. Using the best algorithm in term of big-O removes a potential problem. Keeping the suboptimal algorithm is actually the hard optimization path, because it requires you characterize your data and maye keep a note somewhere explaining why you chose that algorithm and its limitations.
- OkayPhysicist 3y ago> your baseline for what performance is possible slows down. This is a problem that absolutely plagues our field. If your project isn't some wrapper around some incredibly complicated math or handling files well into the GB range, there's no excuse for a desktop application to take noticeable time to do anything. Yet here we are, with it taking about a half second just to open the search bar on windows. What is it doing? Why does it take so long? Who knows?
- F-W-M 3y agoIO on the UI thread.
- simplotek 3y ago> The hard part is knowing what "stupidly inefficient things" are. There are things that are quite obvious non-critical in terms of performance. One time I had a junior engineer insisting in a PR that we should use a few low-level performance tricks in a code because it was fast, and the code was to open a dialog box. Also, in general performance bottlenecks are caused by architectural and algorithmic choices, not readability choices. If we're in a domain where, say, inheritance is an unacceptable performance bottleneck and we need to unroll loops and we can't extract functions because the cost of pushing the call stack is prohibitive... We are in an extremely performance-sensitive part of the code. But most of the time we're far from any of that.
- gpderetta 3y agoIf inheritance and function calls are a bottleneck, it is probably the time to change programming language.
- danielvaughn 3y agoYep, it's entirely possible to get into a scenario where you can't determine where things are inefficient, because the inefficiency is everywhere. Once you're in that spot, you're in for a bad time.