2 ms·
> Cost is a business problem. It is a constraint I 100% agree. What I'm trying to get across is that you have to identify the cost to justify the performance t
by xupybd 4y ago
> Cost is a business problem. It is a constraint
I 100% agree. What I'm trying to get across is that you have to identify the cost to justify the performance tuning. If the cost of the tuning is greater than the cost incurred by not doing you might not want to do it.
What are your actual costs and how do they line up? Are you writing ML and big data then processing costs are huge. You can probably win by spending money on developer time to reduce processing costs. On the opposite end of the scale are you writing CRUD for a small business, then the development costs are likely to outweigh any costs from inefficiencies in the applications code.
To me the article read as if our job was to make every bit of code as fast as possible. I think we should only spend time on code that meets the greater goals of the system it operates in.
If you identify that run time is a cost then you have to identify what part of the code is the bottle neck and fix that. Then you have look back to see if any more improvements will be worth the time invested.
- sakras 4y ago> To me the article read as if our job was to make every bit of code as fast as possible. My interpretation was that he thinks the baseline for performance is too low. There are kind of two parts to performance: non-pessimization and optimization. He’s mostly harping on the former point, that you don’t have to go tuning anything. Just by writing code without following the clean code rules you can get a huge speed up for free, without any tuning at all. It’ll be free of obvious overheads, even if it doesn’t do anything special to fully utilize the hardware.
- inkblotuniverse 4y agoThere are 1000x gains on the table! Almost all software is so far from pareto-optimal it's comical! It isn't a tradeoff between readability and efficiency, most software is unreadable and inefficient! When every function in your program is virtual, fixing bottlenecks won't give you a significant speedup. You don't need to optimize programs to make them 1000x faster, we just need to stop shooting ourselves in the foot.