Speed or Productivity? Debate Goes On

 
 
By Peter Coffee  |  Posted 2002-06-17 Email Print this article Print
 
 
 
 
 
 
 

Developers' tool choices used to be made with a stopwatch, back when compile times were measured in minutes and desktop PC speed was the client's limiting resource.

Developers tool choices used to be made with a stopwatch, back when compile times were measured in minutes and desktop PC speed was the clients limiting resource. Todays performance bottlenecks often reside at a distance, whether in network bandwidth limits, in opaque run-time environments or in server-side code.

Should developers still use tools that let them write the fastest-possible code, even if that means spending costly programmer hours to enforce good behavior? Or should they take advantage of the higher productivity that comes from Javas elimination of many common sources of programmer error?

Borland Software Corp.s JBuilder (reviewed above) was one of the first developer tools to exploit what could be known about a Java application, parsing code dynamically for feedback during development. Oracle Corp.s JDeveloper now gives JBuilder a run for its money in this regard, but so does Microsoft Corp.s performance-oriented C#. The choice of productivity or performance is no longer a choice between Java and everything else.

What remains is the tension between writing code that takes corners on two wheels, with facilities such as unsafe pointer operations, and using tools that do more to keep the code on the road—while avoiding the problem that "it is very easy to write slow Java programs," as warned by software performance guru Dov Bulka, performance architect of IBMs Domino-Go Web server, in the preface to his book "Java Performance and Scalability, Volume 1: Server-Side Programming Techniques." Bulka particularly warns developers to "keep a watchful eye on the number of objects our code generates on the performance-critical path."

Overall, hardware performance trends put eWeek Labs on the side of making code do the right thing before worrying about how fast it does it. Developers should take the time to learn what makes code slow, but its better to have a list of performance improvements to make in code that works than to wonder why it falls apart so quickly.

 
 
 
 
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel