Make It Snappy!

So there's been this thread on the cf-talk mailing list in the past couple days about performance. Of course as a developer, I generally end up performance tuning just about everything at some point or another... although I hate doing it. I realize that performance tuning is necessary, but I hate doing it because that means instead of creating an interface to accomplish a new goal for my customer, I'm just making it possible for them to accomplish a previous goal very marginally faster.

The analysis usually goes something like this:

• I would really like for users to be able to send email to x group of customers at once. There is currently no way for them to achieve this goal using the existing system, except to manually comb through the list of users in that group and copy their email address into a text file or enter them into their email client. Doing this in some cases would require an hour or more of tedious leg-work for the customer. A tool to do this would allow them to achieve this goal in mere minutes or even seconds.
• Users are upset (and raising hell) about the fact that it takes 12 seconds to load their list of most-used and most-recent contacts. Improving performance here would reduce the wait from 12 seconds to about 4-6 seconds, imo a marginal improvement.
• I have 5 hours of development time. So instead of creating the tool that lets them do in a few seconds what currently may take over an hour, I'll spend the next 5 hours tediously shaving off mere milliseconds from the process they're complaining about.

For some reason that I don't think anyone really understands, humans (customers) seem to be totally unable to put the previous example scenario into proper perspective. Now I'm not blaming the customers here, I'm just saying, that's the reality of the situation. And I accept that it's likely I even do the same thing when the shoe is on the other foot and I'm the customer.

I was just thinking about this not only because of this thread on the cf-talk list but also because I've been preparing to create a video presentation for this contact manager I've been working on. In the thread, Jim Davis points out that most companies tragically overlook usability. It's true, most companies don't do anything about designing for usability (you might call it "ergonomics") in spite of the fact that it's probably the single most important thing you can do period when developing software. Further when they realize that there is a problem, they usually misdiagnose the problem and misprescribe a solution.

AJAX is a great example of this. Companies seeing that there is a problem and misunderstanding that problem have glommed on to the AJAX bandwagon left and right, shouting "give the programmers AJAX! It will solve all our problems!" They have yet to realize that simply putting bells and whistles in front of a bunch of guys who don't know how to do usability in the first place hasn't helped them learn usability at all. Now they just design horribly unusable AJAX applications! They commit heinous crimes against humanity like using CFWINDOW everywhere.

This is good news for me of course, because I spend so much of my time focusing on the ergonomics of my own software. I of course use AJAX or at least AJAX-like features. But I also do my damnedest not to be a man with a hammer, viewing every problem as a nail that can be driven with the same tool. In spite of how much I might use certain specific tools such as the SQL abstraction layer or the XHTML abstraction, there are always cases in which the preferred tool isn't the best tool for the job.

Like I said I hate performance tuning, and I've been doing more of it recently because I've been prepping for this video presentation for my contact manager. I mentioned in a blog the other day that I had tuned the RegionManager in the Members onTap plugin. There I had eliminated several uses of the SQL abstraction layer in favor of storing larger queries in memory and using the ColdFusion server's built in Query of Query feature to pull nested set information to get the ancestors or descendants for a given region. It turns out that simply storing those queries in memory is a notably better tool for the job.

And now I find myself doing the same thing with one of the displays for the contact manager. I had already created several CFC objects to store information about this particular display, which loops over two queries to display information from them. I'd created the CFCs as an alternative method of customizing the display for this page, which then generates XHTML that goes into the framework's XHTML syntax, gets transformed with XSLT more than once and becomes a set of structures before finally being converted into a string and passed off to the browser. That means there were 3 separate ways to customize this page between the CFCs, the XSLT and the XHTML tools.

The problem is all these join-points are creating all the overhead in the display and given that this isn't a page where a user has requested something specific (and would therefore be willing to wait longer), this particular page needs to be faster. So it looks like I'll be moving away from the XHTML library and the associated XSLT (most of which is unused on this page anyway) to simply having the CFCs generate the HTML directly in this case. The CFCs themselves are lazy-loaded and cached once for the entire application, so once I've removed the XHTML the performance should be pretty darn close to the performance for cf templates that use no framework at all.

And over the years, "it's slow" (without any kind of qualification of what they mean by "slow") is the biggest and most frequent complaint I hear from people about the framework. WHAT is slow?! Did you disable the development mode?! What are you using for a server?! (I use a notebook for development and expect it to be slow.) Are you caching any of your display? (Did you know you can cache your forms?) What are you loading? How are you getting it from the database to the browser? What is the user trying to accomplish? How many seconds do they have to wait? (I see people make the same unqualified complaints about the performance of other packages too - FarCry for example.)

And several people have made this comment specifically about the forms tools, which have been performance tuned gradually over time, however... a form is the one place where performance tuning is even less important than anywhere else in your application! The user understands that the system is working for them and they'll wait an extra second or so for the form to load. But even better would be designing systems that reduce their dependence on forms, especially complex forms. The contact system I'm designing provides no less than three separate context-appropriate interfaces (possibly four) for associating a user with an organization. Only one of them even involves a form and that form has only two input elements which incidentally load with lightning speed.

Yes I advocate using the XHTML library for a lot of things, and yes it automatically takes longer than writing content directly to html, but it's also not the best tool in every scenario. I advocate using the XHTML library a lot because it handles a large variety of tasks well with minimal programming work. If it's not suited to a particular task, you just have to go back to more traditional development.

And if you're going to complain about it being slow, for god's sake, give me a clue what the context is, because a) it's usually not as important as it seems and b) if it is important, there's probably a better way to deliver the content (which will sometimes require more development time).