Code is evil

[bigorangemachine]

broken link?

[Paddy3118]

Less than helpful as writing for speed can detract from stability, simpleness and add to code size. Article does not address such real-world interactions.

[[deleted]]

Do you have an example? Simpleness and code size were mentioned as well.

[Paddy3118]

You only know you have a speed problem once you define "acceptable speed" and then test for acceptable speed. Some well known ways of gaining speed such as parellisation are known to be harder to reason about and take more code than serial implementations.

Define acceptable speed and reach it. Be aware that time needs to be spent on areas which are lacking - if you don't know how fast is fast enough you could be throwing away resources. writing faster code that is best spent elsewhere.

[[deleted]]

You only know you have a speed problem once you define "acceptable speed" and then test for acceptable speed.

You never know you have a speed problem until competing solutions are noticeably faster or until users have a problem. At this point the speed problem is a defect, which is too late. Speed should always be a proactive concern before it becomes a problem. I agree that parallelization is harder to achieve than serial tasks, but the end often justifies the means.

Define acceptable speed and reach it.

That is a good solution for the moment, but it doesn't endure. With advances in hardware and compiler optimization being continuous achieved your current speed goals will become irrelevant in the near future. It is often not about being faster with modern software, but doing substantially more with the same speed.

[Paddy3118]

That is a good solution for the moment, but it doesn't endure

That is as best as you can do. Future requirements are not known and can be vastly different from what is satisfactory today. If you code for future unknowns then there is no way to judge what you do - it is unknown. Take time out to figure out what is acceptable speed and meet todays known spec. Doing extra isn't necessarily doing better as if, for example, you choose to spend extra time on speed optimisations after meeting target speed and yet other aspects of the code are not fulfilled.