Scott just posed an interesting question on his blog. I think we all agree that focusing too much on performance upfront to the detriment of maintainability or functionality is not usually a good idea. But equally, none of us would write an app that deliberately included every bean being created in the request scope and n+1 queries. So, what is just common sense or best practices and what would come under premature optimization?

To me it is more a state of mind or focus than anything else, but I'd love to see people post comments on Scotts blog about what they do and don't generally consider "best practices" vs. PO.

Thoughts?!

Ben Nadel posted an interesting piece the other day about his requirements for a page rendering system. One of the things he was looking for was an approach that allowed you to defer as much processing as possible to allow for at least partial page rendering as quickly as possible to give the perception of shorter load times on the basis that users consistently report lower perceived load times for pages that start to render quickly even if the total page load is the same or even slightly longer.

There are two issues that need to be addressed when looking to implement such a solution. CF locations and dependent content areas . . .

[More]

I remembered Charlie Arehart mentioning iBATIS a while back, so I finally took a little time to go through some of the articles on iBATIS.

[UPDATE] Charlie's blog posting on the subject. Well worth a read!

To summarize iBATIS allows you to use XML files to map your business objects to your SQL statements. It seems pretty easy to learn and is being proposed as an alternative in the Java and .NET worlds to (n)Hibernate and other ORMs.

[More]

In an ideal world, all of our objects would just exist. No databases, no joins, no discussions over table inheritance. We’d just go to an object and the data we want would be there.

This is not an ideal world.

There is no such thing as the perfect ORM as database access is one of the tasks that has the greatest impact on application performance (this is more than just premature optimization) and every application wants different information in a different way. I want to look in this posting at some broad approaches to retrieving relational data for an OO application and some of the implications of each.

[More]

I realized that in my last post I mentioned the n+1 query problem without really explaining it, so if it is something you never really "got" or haven't heard about, here is a simple explanation.

[update] And thanks to Gus and Al Davidson, some sample SQL for avoiding the problem - check out the comments!

[More]

I just wanted to mention a pretty common design pattern that I know a lot of us use, but I thought it might be worth having a reference to this pattern somewhere on the blog.

Often you come across a problem where an application needs to be able to change it’s behavior without reprogramming and where language limitations make it difficult to implement a solution using dynamic programming.

For example, lets say you would like to be able to allow administrators to add, edit and delete the fields displayed within a contact form. That is pretty straightforward. With enough metadata about each field, you can just loop through the field list dynamically and generate the appropriate HTML to display it. But what happens if you’d like client side Javascript and would like to take advantage of cfform’s ability to generate the code?

[More]

A very common approach to persistent data access and management in ColdFusion is to use a (data table) Gateway for bulk operations and a DAO for single record operations. A corollary is that the DAO usually returns a loaded bean whereas a Gateway usually returns a query.

There is a problem with that – I don’t want to have to write all of my views twice! . . .

[More]

Sean Corfield once told me that he was not a big fan of application generation. The title of this blog notwithstanding, I agree. Often application generation is a sign of premature optimization.

I am however a huge fan of declarative metaprogramming (where you just tell the computer what you want your application to do and let existing generalized code figure out how to make that happen).

[More]

Firstly, please note Duck typing (see Sean Corfields excellent presentation) is NOT primarily about performance. In most cases this is probably the least interesting aspect of it. Using duck typing to improve performance before identifying a performance bottleneck is a sure sign of Premature Optimization :->

Once you have a working application with a performance bottleneck which can be attributed to a large number of method calls each of which does a relatively small amount of processing, it is time to consider taking advantage of duck typing to improve the performance . . .

[More]

An embarrassing condition that afflicts programmers who are so concerned about performance that they can't wait to build an application before they shoot off to improve the performance of parts of the application that probably would never become performance bottlenecks anyway.

Written by an occasional sufferer.