operator[][](const int i, const int j)

Quote:

---

Originally posted by AnthonyMai
The point I want to make is nowadays, in general, there are much more applications that hunger for better performance, than those that does not.

Ultimately, it is a world of Darwinism, of survival of the fittest. And the fittest being those who can push efficiency of stuff, be it hardware, software, whatever, to the extreme. The whole history of how the industry civilization progressed is a history of relentless pursuit of power and efficiency. Isn't it true?

---

How can you mention bloatware without mentioning Microsoft?
I love Microsoft; I think they changed the face of personal
computing. I abhor all of the idiosyncracies of unix programming
... but no matter how much I love them [and ignore their immoral
business practices], their products are just plain slow.

I certainly wouldn't characterize Microsoft [arguably the leading
software vendor in the world] as pursuing either power or
efficiency. Microsoft has repeatedly shown that it can take a LESS
efficient or LESS technically-sound solution and make it work
through brute-force marketing.

--Paul

Quote:

---

How can you mention bloatware without mentioning Microsoft?
I love Microsoft; I think they changed the face of personal
computing. I abhor all of the idiosyncracies of unix programming
... but no matter how much I love them [and ignore their immoral
business practices], their products are just plain slow.

---

Believe me I am definitely not a big fan of Micro$oft. But honestly they are neither more bloatware or less bloatware than others. They are just more prominent so we notice.

There was unfortunately an era when bloatwares prevail just like there was an era on earth when bigger and bulkier prevailed and dinasaurs ruled the world. As you know then the ice age came, dinasaurs distincted and leaner animals that are more efficient in predating and in surviving on less food prevailed.

Quote:

---

True, but efficiency to keep production costs down. Optimizing software does not keep production costs down. The two are completely unrelated.

---

Production cost is irrelevant to optimization. Rewards for the time and effort programmers put in creating a software product is generally a very small portion of the "product cost". The extra time and effort one needs to invest in making a software more efficient takes even less portion in the total "production cost", because chances are only 5% of the code are real performance bottlenecks and improve that 5% improves the overall performance.

Microsoft's Windows 2000 contains 39 million lines of code. It was the creation of a team of less than 200 people. Microsoft was said to have invested 5 billion dollars on Win2K, that's $125 per code lines, or $25M per programmer. Now tell me how much do Microsoft programmers actually get paid?

In general, the programmer cost is almost a negligible part of total production cost. The cost of optimization is even less.

I've read all your discussions with a lot of interest. I've worked over 10 years optimizing time-critical programs to improve performance, and certainly feel that performance considerations are preferable to bogged-down slow programs all the time, whether the program is a simple calculator or a large real-time program. How many times have you pressed a button in a program and could go to lunch while the program was "thinking" of what to do? I've seen those types of programs and hate them! A few years ago I rewrite one program that took over 12 hours to do its job. That time was reduced to 10 minutes or less.

Client/server database programs are netorious for this. I'm working on an application now that when you press the Submit button the program takes several minutes to process the information. Very little of this time is due to network traffic, but most of it due to careless or inefficient programming. One programmer told me "So what if it takes several minutes!" From a tehnical programmer's view it doesn't really matter at all. But from the user's view -- uggggg! In the trash can with that product!

C++ is a nice programming language and I like it a lot, and programmers can get into the misguided impression that efficiency comes with fewer programming lines. The discussion about the 2d arrays is an example. Nice and easy to read, but runs too slow. Which is more important -- source code that is pretty to look and easy to read but runs like a dog, or source code that may be harder to understand but runs like a champ? Personally, I favor the latter any time.

Quote:

---

From Me:
True, but efficiency to keep production costs down. Optimizing software does not keep production costs down. The two are completely unrelated.

---

Quote:

---

From You:
Production cost is irrelevant to optimization.

---

If you go back and find the context that I stated that in, you'll realize that that was my point exactly. You were using a flawed argument about efficiency in industry, and I was merely pointing out your flaw. Thanks for agreeing.

Quote:

---

Originally posted by stober
source code that is pretty to look and easy to read but runs like a dog, or source code that may be harder to understand but runs like a champ?

---

This is not a cut-and-dry issue. There is often a direct trade-off between performance and maintainability. Maintainance is the largest cost of software development. The bottom line is the bottom line of the budget. Performance concerns should be secondary to maintanance issues. I am not saying ignore performance. I am saying don't optimize a good design until you have a well-defined bottle-neck and a reason to improve it.

I come from a performance-minded company. We spend a decent amount of time profiling and making improvements. Maintanability is still king. One of our packages has been around for 10 years, the other for 35 (that's right--began with punched cards).

Jeff