Premature optimization is the root of all evil

[vak]

Here is a more detailed elaboration.

1. Make it work.
2. Make it right (the code is readable [uses intention revealing names] and every idea is expressed once and only once).
3. Make everything work.
4. Make everything right.
5. Use the system and find performance bottlenecks.
6. Use a profiler in those bottlenecks to determine what needs to be optimized. See Profile Before Optimizing.
7. Make it fast. You maintained unit tests, right? Then you can refactor the code mercilessly in order to improve the performance.

-- Guillermo Schwarz

Comments

[1master]

Более того, нередко выясняется, что первых трех пунктов достаточно.

[vak]

Подозреваю, что большинство софта и до второго пункта не добирается. 😀
Многие приложения короткоживущие. Используются несколько раз и перестают быть нужными.

[sobriquet9]

Nowadays I seriously consider "once and only once" to be an antipattern because applying it in practice usually reduces redundancy at the cost of increasing dependencies, which is not a good tradeoff in my book.

[vak]

Well, better without fanaticism, of course.

[juan_gandhi]

It's a good list. I'm always trying to do it like this.

As to the names, at times one has to use backticks::
val `Set^𝟛`: CategoryOfDiagrams = toposOver(`𝟛`)

But, otoh, a refactoring can break thing seriously, and if the refactoring is ideologically correct... it does take efforts to fix things.

[juan_gandhi]

Sounds convincing, but in such a case I'd rather think about choosing the right abstractions.

[kondybas]

когда система доживает до №5 - меня зовут на контракт :)

[sobriquet9]

Every problem can be solved by adding another abstraction level except the problem of having too many abstraction levels.

[juan_gandhi]

Not actually. The lower levels turn out to be just specific examples, and may be omitted.

[sobriquet9]

Industry practice is to pile abstractions on top, though. Instead of caveman copy-modify, create recursive currying singleton token observer accumulating wrapper factory.

[vak]

In my previous company we had to kill a large C++ product because it's source base became totally unmanageable due to huge pile of unneeded abstractions.

[juan_gandhi]

Not the industry I saw. What I observed was always either rewriting everything or adding small features.

Which industry you are talking about? Companies like Oracle? Or some other Indian Enterprise?

[sobriquet9]

I've seen it play out in several industries — financial services, medical diagnostics, payment processing, etc.

Even in embedded programming as soon as controllers became sufficiently powerful, people started piling abstraction levels on top of each other, and soon any change required unwrapping and often drilling holes through those layers.

[juan_gandhi]

Hmm, embedded. See, there were times I did embedded (and not) with Forth. I love Forth because you can grow the pyramid of abstractions very fast and efficiently. But of course it must be well-architected. Not patches over patches.

[sobriquet9]

I considered FORTH for that use and decided against it. C with inline assembly resulted in code that ran faster on the hardware that we had at the time, but more importantly the standard library was way better.

[juan_gandhi]

I find this ridiculous. My Forth implementation of FPP was about 40% faster than Borland's C implementation - the "standard library". The reason being, in Forth, using macros, you can manipulate the contents of registers semi-automatically, the knowledge spreading over a thousand lines. You can't optimize your C code like this; your scope is just several lines, and your manually-written assembly scope is probably just dozens of lines. You need macros to manage it better.

Of course, in small solutions, like `strlen`, it does not matter in small functions (saying it as I'm the one who made Borland's `strlen` about 4 times faster.)

[sobriquet9]

You're arguing with a stopwatch. There was an interrupt triggered by hardware every 20 milliseconds. Interrupt handler then read accumulated data from the sensor, processed it, and updated display buffer directly. C code could do it in time, after I hand optimised it to use string operations that were supported by the CPU (but not the compiler). FORTH was not even close.

And it was much easier to write the rest of the logic (polling the keyboard, user interface, calculating necessary metrics) in plain C, using the expansive C standard library.

[juan_gandhi]

What I read here:
- you were. more comfortable with C than with Forth
- your Forth was not good enough to write fast code
- you didn't have enough experience with Forth to write ui and calculations in Forth.

Ok, but it's not the problem with Forth. Once we two, me and my colleague, had snapped together a drilling site simulator (including ui, sensors interactions, formulas interpretation (formulas entered by the user). We spent one week on it. Before that we spent three weeks writing a dedicated Forth system and drivers, all in Forth. And of course our code was pretty fast.

But again, we already had over a year of Forth experience, with our one Forth core, and with an experience of its industrial use (in drilling control).

What I want to say, that it's not about Forth at all, it's about one's tastes and experiences. Those days I could use C, and I've always respected C.

[sobriquet9]

My FORTH was as bad as my C or my assembler, but it does not really matter because the operation in question was so simple. There isn't that many ways to copy from one memory area to another. Whichever language you use, if your compiler does not convert the loop to string opcode and does not give you ability to do so, it's not going to be as fast. Back then there was no speculative execution so I could look up the number of clock ticks it would take from the opcode table, and even see read operations with oscilloscope to confirm. And it wasn't a small difference, it was the difference between a device that worked and device that didn't.

[juan_gandhi]

A more open mind may help solving problems.