GridMonger is an application that, in several respects, shows just how versatile ColdFusion can be. It is an application that, coming out of the gate...
- Does not know how many fields you will display, or which fields will be editable, or if editable how they will be displayed during the edit.
- Does not know the names of the fields.
- Does not know the datatypes of the fields.
- Does not know which database platform you are using.
- Does not know which version of ColdFusion you're running.
- Needs to keep track of its own settings as it goes along (i.e. last row displayed, edited and so on)
- Needs to be dynamically self-aware, so different settings can be user-determined for each grid, and those settings are unique to each grid in case more than one is in use; and work even if more than one are on the same page.
The net result of all this is that there are a lot of loops inside the code, trying to figure things out.
Loops, and dynamic variables...
well, actually its loops and dynamic variables and evaluate() statements ...
but if we were to come clean its loops and dynamic variables and evaluate() statements and list operations (lists are used to keep all the parameters easy for users to input)
If you've been around ColdFusion for any length of time you know that the above are all individually known to be ingedients of a recipe for bad performance. Together, they make up a worst-case scenario. Peek in at the code and be prepared to gasp out loud.
However, oddly enough, GridMonger is quite fast when executing by itself. Despite all of the nasty things hiding under the hood, what really drags down performance is the database.
Using a 1000 record dataset in a mySQL database (the zip code db included in the GridMonger download) and either a 10- or 20-row display, execution of grid templates is between 95ms and 140 ms. Full screen Multi-Edit and Multi-Add operations climb into the 250ms range.
Switch from mySQL to the supplied Access database and you can expect the max performance hit on the sample database to be in the 300 to 350 ms range.
Using mySQL tables with recordsets in the 15,000 record range drags performance, but its still sub-500 ms.
All of our unscientific benchmarks were made on a fairly hot, dual-2ghz Xeon workstation with 2gb RAM and running Windows 2000, CFMX 6.1 Standard and either mySQL 4.0.16 or Access XP.
NOTES on v3.40:
Knowing the performance drags that come with list operations and all those evaluate() statements, we spent a fair amount of time rewriting things to try and enhance performance. However it soon became clear that we were throwing pebbles into the ocean, and we quit that part of the project: its the database thats the real determinant of speed here.