5 ms·

Did you not read the whole thing? There's a whole story (about a criminal api venture) where the point is stated that speed-ups that look pretty small have kno

by Kamq 4y ago

Did you not read the whole thing? There's a whole story (about a criminal api venture) where the point is stated that speed-ups that look pretty small have knock on effects that allow for opportunities elsewhere, and that these opportunities snowball until something significant happens.

SoftTalker 4y ago
It would have been helpful to get to the point. Not eveyone has the better part of an hour to spend on a single web article.
bawolff 4y ago
Yes i did. That's how i got to, if you dont understand the problem you might accidentally succeed. It is true that knock on effects are a thing, and small fixes can sometimes have suprisingly big returns. However most small fixes do not, especially in programming. The art of optimizing is understanding the problem well enough to find the right 1% speed improvement to make, because you cannot do all of them and most don't. What i took away from the article (after all the obnoxious long winded irrelavent tangents that went nowhere), is basically dont dispair if the fixes look small because you might accidentally stumble upon an important one that isn't small without realizing it. Which i find to be a depressing, two wrongs sometimes make a right, take.
- jacquesm 4y ago
  That's why you profile. Software tends to get super complex as you add features and without a very thorough understanding of what is going on chances are that your program is doing something else than what you think it is doing, or at least that it is spending it's time on something else than what you think. By profiling you get a grip on that and this in turn allows you to spend your time on that 1% of the code where it spends 99% of the time. By the time you're done optimizing that a new bottle-neck will have arisen and so on. I've had software that was performing marginal end up being too fast to measure accurately over the course of a few iterations, and that's when I thought that I knew what was going on. If Donald Knuth suffers from this as well then I wouldn't berate myself too much about it, his famous quote that 'premature optimization is the root of all evil' then you're more than excused to let optimization rest until the code is correct (which is far more important than that it is fast) and then use a profiler to tell you where to most efficiently apply your attention. This will get you to a very high percentage of the optimum in a relatively short time.

by Kamq 4y ago

SoftTalker 4y ago

It would have been helpful to get to the point. Not eveyone has the better part of an hour to spend on a single web article.

bawolff 4y ago

Yes i did. That's how i got to, if you dont understand the problem you might accidentally succeed. It is true that knock on effects are a thing, and small fixes can sometimes have suprisingly big returns. However most small fixes do not, especially in programming. The art of optimizing is understanding the problem well enough to find the right 1% speed improvement to make, because you cannot do all of them and most don't. What i took away from the article (after all the obnoxious long winded irrelavent tangents that went nowhere), is basically dont dispair if the fixes look small because you might accidentally stumble upon an important one that isn't small without realizing it. Which i find to be a depressing, two wrongs sometimes make a right, take.

jacquesm 4y ago
That's why you profile. Software tends to get super complex as you add features and without a very thorough understanding of what is going on chances are that your program is doing something else than what you think it is doing, or at least that it is spending it's time on something else than what you think. By profiling you get a grip on that and this in turn allows you to spend your time on that 1% of the code where it spends 99% of the time. By the time you're done optimizing that a new bottle-neck will have arisen and so on. I've had software that was performing marginal end up being too fast to measure accurately over the course of a few iterations, and that's when I thought that I knew what was going on. If Donald Knuth suffers from this as well then I wouldn't berate myself too much about it, his famous quote that 'premature optimization is the root of all evil' then you're more than excused to let optimization rest until the code is correct (which is far more important than that it is fast) and then use a profiler to tell you where to most efficiently apply your attention. This will get you to a very high percentage of the optimum in a relatively short time.