OSNews

"Depends on the case, but yes, the first prototype *can* be a major investment. Point is, if you invest in anything else, your investment is most likely lost."

This is a generalization, what do you really mean here?

"A prototype then often shows you the right direction."

Of course.

"No. The prototype isn't for performance analysis. You build it to see if your whole project is heading in the right direction, because if it isn't, any performance optimization is wasted time."

Again, you are the one who brought the prototype into the discussion, no one here has said anything about needing to optimize the prototype.

What I did say was that it is important to analyze and predict potential efficiency problems with the design before getting so far into development that it's hard to change. As far as I can tell, your statements like the following seem to agree with my reasoning.

"If the direction is right, the prototype next shows you not how to make the design efficient, but whether efficient design is actually needed."

"See, for example, the above-mentioned Minix mkfs example. In real projects, developers will have it much harder to "guess" how often functionality is used than with mkfs."

I'd wager a guess that the Minux mkfs probably worked within one week and that the student was optimizing it afterwards for six months. If this is the case, then it's not really relevant to a discussion on early optimization. Either way, we agree this situation was ridiculous.

"It means that if you detect performance problems late, you'd still fix them. Just as if you detect other fundamental design issues late, you fix them."

But fixing them late can be magnitudes harder such that many projects simply give up on the notion of fixing them, please see my earlier examples.

"So you don't build such pieces; you build pieces that can be changed even at a late point in the development cycle."

Whether we like it or not, there comes a time in many projects where we pass a point of no practical return. For example the choice between threading, poll/select(), multi-process, or AIO is needs to be decided early on. No matter how good your final design is, it requires a great deal of effort to change models - every single IO point is potentially affected.

Sure it can be done, but those of us with optimization experience can void many performance problems such that we wont have to cross such bridges later on. Again, see my earlier examples.

I'm not talking about profiling each function or anything like that, is that what you're thinking? I'm really referring to optimizing the overall design for performance at a higher level.


"A hobby OS doesn't have users, it does not have requirements, and maybe you optimize performance just for the fun of it. It does not make sense to ask whether performance is 'sufficient' when nobody is actually using your OS for anything."

True, but sometimes those pet projects become famous and for better or worse the future has to deal with legacy decisions whether or not they were well thought out.