Timeline for When is it better to optimize a software for better performance, at the beginning or at the end of the development?
Current License: CC BY-SA 4.0
25 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 21, 2018 at 0:02 | history | edited | candied_orange | CC BY-SA 4.0 |
added 28 characters in body
|
| Apr 2, 2018 at 5:49 | audit | First posts | |||
| Apr 2, 2018 at 5:49 | |||||
| Mar 11, 2018 at 3:12 | history | edited | candied_orange | CC BY-SA 3.0 |
added 15 characters in body
|
| Mar 10, 2018 at 23:25 | comment | added | candied_orange | Let us continue this discussion in chat. | |
| Mar 10, 2018 at 23:17 | comment | added | candied_orange | @svidgen readability makes slow code difficult to write because I don't want slow. It's hard to write what I don't want when I can easily understand what I've created. It isn't just speed that correlates here. Correct, consistent, thread safe, logable, cohesive, orthogonal, loosely coupled, everything I want my code to be is subservient to being readable. If I focus to hard on any one of these others it's all too easy to sacrifice other things I want. If I focus on readability it's hard to lose a single one of them because I can see at a glance what I've done. | |
| Mar 10, 2018 at 22:38 | comment | added | svidgen | I'm curious. I'll assume your experience has shown a positive correlation. But, if you look back at your career, and all the devs you've worked with, and if you correct for years of experience and skill, does the correlation still hold? ... Or, could it be that "better devs" just happen to be better at writing both readable and efficient code? | |
| Mar 10, 2018 at 22:36 | comment | added | svidgen | If there is a correlation, it is that inexperienced developers tend to write both slow and unreadable code. But, you're claiming something much harder to prove: that readability and efficiency are positively correlated on their own, even suggesting a casual relationship. That's just a really bold, really unfounded claim, which is contrary to popular wisdom (at least in some domains). I'm not sure I can drum up evidence for these things being orthogonal, because it's mostly just "lots of experience." But, I'd like to know why you think readability makes writing slow code "difficult." | |
| Mar 10, 2018 at 21:46 | comment | added | candied_orange | @svidgen Sorry if I've missed your point. Please teach me why you feel there is no link between unreadable code and slow code. | |
| Mar 10, 2018 at 21:14 | comment | added | svidgen | Missing the point. I agree with your general point. But, to claim that writing readable code somehow protects you from producing slow code is just absurd. | |
| Mar 10, 2018 at 20:44 | comment | added | candied_orange | @svidgen evaluating the speed of unreadable code without tests is next to impossible. Focusing on speed and ignoring readability creates undiagnosable speed problems. Focusing on readability makes speed problems so obvious you won't have to think about it. You'll see it the moment you write it. Even if you don't, once you test it at least you'll be able to find the problem. Given all this, why should anyones default focus be on speed over readability? Focusing on speed and ignoring readability gives you neither. | |
| Mar 10, 2018 at 19:52 | comment | added | svidgen | I don't disagree with the general point -- but, you've got one very questionable statement: "It is remarkably difficult to write slow code when you focus on being readable." ... Leaving aside my anecdotal experience suggesting the contrary (with reasonably experienced and competent dev's, mind you), I see zero causal relationship between "readable" code and "not slow" code. For me, that claim makes the whole answer feel dubious. It suggests (to me) that you don't have enough breadth of experience to issue a trustworthy answer ... Please prove me wrong! | |
| Mar 9, 2018 at 17:07 | comment | added | Doc Brown | @PieterB: or you have a client who wants to get his money back because the product they bought is so buggy they cannot use it. | |
| Mar 9, 2018 at 13:40 | history | edited | candied_orange | CC BY-SA 3.0 |
deleted 4 characters in body
|
| Mar 9, 2018 at 13:25 | comment | added | Walfrat | @DocBrown I was not sure if it had to be read raw or interpreted, because it can also be interpreted at a higher level : when you think about your code, you're not only making it more readable but also avoid commons pitfalls. | |
| Mar 9, 2018 at 13:21 | comment | added | Pieter B | @DocBrown I fully agree with the slowing down etc. but at that point you have a paying client. | |
| Mar 9, 2018 at 13:08 | comment | added | Doc Brown | @Walfrat: I think your example can be easily sped up without sacrificing readability, and I am interpreting this answer not as "readable code does not have any performance problems", but more like "perfomance problems won't automatically be avoided by making code unreadable". | |
| Mar 9, 2018 at 12:48 | comment | added | Walfrat |
It is remarkably difficult to write slow code when you focus on being readable. So much so I generally ignore performance until given a reason to care. for (blabla){f = fopen("..."); putchar(f, c[i]);}. That is readable, yet an absolute horror, so I have to disagree with your statement, (however this is easily fixed). And bad design, just doesn't get fixed later, it doesn't get fix at all generally.
|
|
| Mar 9, 2018 at 12:48 | history | edited | candied_orange | CC BY-SA 3.0 |
added 70 characters in body
|
| Mar 9, 2018 at 12:20 | history | edited | candied_orange | CC BY-SA 3.0 |
added 2 characters in body
|
| Mar 9, 2018 at 12:14 | history | edited | candied_orange | CC BY-SA 3.0 |
deleted 11 characters in body
|
| Mar 9, 2018 at 11:02 | comment | added | Doc Brown | @PieterB: it is remarkably easy to slow down development by a strategy like "bugs and bad design can be fixed later". Note, by bad design I mean things like unreadable, convoluted code, as well as overengineered code. | |
| Mar 9, 2018 at 10:52 | history | edited | candied_orange | CC BY-SA 3.0 |
added 1 character in body
|
| Mar 9, 2018 at 8:58 | comment | added | Pieter B | I've always found that the number one thing software developers should focus on is getting a product on the shelves as fast as possible with as pretty an interface as possible, bugs and bad design can be fixed later. | |
| Mar 9, 2018 at 0:58 | history | edited | candied_orange | CC BY-SA 3.0 |
added 11 characters in body
|
| Mar 9, 2018 at 0:39 | history | answered | candied_orange | CC BY-SA 3.0 |