R
@tgape said:@random_lurker said:@dhromed said:Don't optimize.Don't optimize yet.Do it differently. I hate that quote. What do you think optimization actually is? If it's the same then it's not optimized.The second thing about this is it means that I have to swim through an absolute mire of code because people don't understand the basics of optimized coding.I point out basic coding "tricks" to speed up the code and you get, "that's optimizing" and they then ignore it. It mean I have a GUI (embedded STB) that takes 10-30 seconds to load, and people are now looking at me asking why it is not quicker.
I believe the 'do it differently' means, perform an algorithmic optimization, rather than just doing little tweaks that speed up individual statements. When it's viable, it does work much better than the former.
That having been said, I personally feel there's a whole world of difference between writing code in a suboptimal way for clarity initially, and only worrying about optimization later, and writing code like a festering wound initially because you can't be bothered to learn reasonable coding, and then performing monkey code "optimization" passes until you find something that appears to be faster. Most of what I see for optimization falls in the latter category, sad to say.*snip* I agree with most of what you say. But, the timescales within the embedded space are minute. To go back and re-write (and re-test) a whole stack of code is just not going to be done. The best you will get is the worst hacked in optimisations during bug fixing before delivery*.Also, code optimization should be done at design. You know how often a function is going to be called, if it's in a frame update function called 30 times a frame, or if it is called once every hour. You can spend time writing the code to the proper level of performance (OK, you wont know how it actually performs to you run for real, but...).The sort of problems I have with programmers that don't think about optimization is that they write systematically sub-optimal code. Structures that can't be optimised, dynamic data structures (on embedded systems), the use of libraries that use an unspecified amount of resources and the best one - "future-safe" or "standard" use of libraries (SQL on an STB is my favorite of all** - it comes up so often - Que the flame war). These can get so deep into a system there is no way to get them out.Trying to optimize this code can mean hours of test runs trying to find out under load where the problem lies. It's tedious and takes far more time than a little extra thinking at coding/design time. But, mostly that phrase can be used to defend the not thinking about optimization/performance, which means we don't get either.*I have been responsible for the most Orgasmically awful speed up/stability hacks in the MINUTES before delivery. Got to love products with fixed delivery dates that can't slip.*** **Most data structures on STBs are defined by standards agencies and broadcasters and don't change often and are fixed size. You do not need a full DB engine to handle them. If they do change then, Menus, InfoBanners and lots of the system (inc. hardware) may have to change, so a new full release will have to be done. You can't future proof that.***It is why I still do this. No better fun (at work) can be had, than while trying to get a system out that has to be on the plane at 5:30 and someone finds a serious bug at 2am, and we don't get paid unless it makes the plane.