<BasicTruth> Designers make various compromises according to their needs. </BasicTruth>
IF your needs are getting something running quickly - or - being compatible with existing code - or - making use of the expertise of team members, you may find yourself using a framework you would not ordinarily use.
You can certainly find pleny of argument about whether framework X, Y or Z is overly complex or slow. This keeps bloggers busy.
So many of our currently popular frameworks/languages/toolkits come from programmers striking out on their own to build a better one.
Don't assume that adding layers of abstraction is always bad, sometimes it illuminates instead of obfuscates.
Using abstractions actually has two positive effects on performance: it accelerates development, thereby leaving more time for profiling and optimization, and it makes it easier to reason about the code, thereby also making it easier to find bottle necks and to remove them.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Justin Russo: (...) Can some one give their kind opinions..
I go with Bill here, what I do - which evolves naturally when using the positioning that Mr. Brogden describes is go read the code the fancy tools produce. Usually it is code written from thousands and tens of thousands of hours of work brought together by someone who is degreed in the field. Thus it provides extremely good sample code for study. I never actually use the fancy tools because they are slow as tree sap on a fouty degree morning.
The citation from Donald E. Knuth comes from a time when machines were rare and wasting a lot of machine time trying to tightly tweak code for fast-path was a super-critical skill. Try to program in the Connected Limited Device Configuration (CLDC) if you want a taste of it. If you can get some code on the page by contemplating super-tweaking, that is today a differing environment from programming on a machine that has the os bootstrap loader on the first two cards of an eighty colum card and runs in 64-k of memory that consists of wire-wrapped pins.
There are others that agree with you.
"The differential equations that describe dynamic interactions of power generators are similar to that of the gravitational interplay among celestial bodies, which is chaotic in nature."
Performance is a non-technical characteristic of a software application. It is defined in a context. To speak generally about performance without a context is not effective, in my opinion.
The primary performance metrics of most business software are the number of user requests or the number of transactions processed in specified time period. For example, 1000 transactions per second, or, 5000 users per hour. These high-level metrics are supported by others such as page rate, response rate, peak load, concurrent load, etc.
When we get these metrics, then we can analyze what performance means for a specific application.
Other software types, such as the control software in an automobile transmission, have a different set of metrics used for measurment. So, performance discussions for this software type will be different than one for business software and/or web-based software. [ April 30, 2008: Message edited by: James Clark ]
Joined: Sep 17, 2006
Originally posted by James Clark: (...snip...)Performance is a non-technical characteristic of a software application. It is defined in a context. To speak generally about performance without a context is not effective, in my opinion.
Correct. A company may want to spend little time and money on it. It the team can deliver that, all other performance issues are not performance issues.