While working on a new application I ran into an interesting issue. The solution to the issue was complex, and I was not pleased with the result. The solution was far from elegant or streamlined. The code was totally bloated, but for necessary reasons. I reworked the code a few times and made it more compact but the end result was still not pleasing.
I bet you are saying, "If it works leave it alone" or something like that. If so I would tend to agree. However, I am one of those people that would spend an hour coding to squeeze out 500ms of processing. I am very critical of what I write and do my very best to make performance paramount.
After leaving the code sit for a few days I want back to it with a clear head. I then started poking around the net looking for ideas. I then started playing around using underlying java objects to make the code better. I then found some undocumented functions in CF that made the code even better.
This is where I hit a crossroad. I was faced with a very perplexing issue. Do I, A: Leave the code alone knowing I could make it better or B: Use some undocumented functions and get the result I was looking for. After pondering it for a while I ended up with option B.
Now, why is this such a big deal? There are many reasons this could be a potential issue. For starters any issues that arise by using an undocumented item are not supported. You can find people that can help you but that would be a very short list. Also, potentially the level of skill required to work in it after you are done could a problem. Then there is the potential that the undocumented item becomes unavailable after an upgrade. This is probably the biggest reason not to do it.
On the other hand, undocumented things usually fill a gap. They provide new functions and tools that are generally unavailable. For instance "queryname.isFirst()" does the same thing as "query.current_row EQ 1". Obviously the undocumented function is more elegant and probably faster. This is just one item in a long list of undocumented items in CF.
Every situation is unique and has unique challenges. Those challenges should be evaluated separately. Do what works for what you are doing. The important thing is to understand the risks involved. If the reward outweighs the risk then go for it. Just be prepaired for the fact that the risk may not pay off.
till next time.
--Dave
#1 by Ed on 5/16/08 - 12:33 AM
#2 by Andy Matthews on 5/16/08 - 4:22 AM
#3 by Ben Nadel on 5/16/08 - 5:05 AM
#4 by todd sharp on 5/16/08 - 5:48 AM
#5 by Ben Nadel on 5/16/08 - 6:35 AM
http://www.bennadel.com/index.cfm?dax=blog:1230.vi...
#6 by Dave Ferguson on 5/16/08 - 7:35 AM
@Ben - I read your blog entry. You are a much better word smith than I. Very well said.
@Todd - I did not intend to say that by using undocumented items I shaved 500ms off the code. It was more of an exaggeration. I was just explaining my tenacity with respects to writing performance centric code.
--Dave
#7 by Ben Davies on 6/17/08 - 8:34 PM
There are many potential bottlenecks in an application, and it usually only 1 or 2 that have significant impacts on application performance. If you optimise your application performance after it is code-complete, you can focus on only the bottlenecks that really matter and will produce the biggest improvement. Over-engineering for performance potentially wastes your development time for minimal savings whilst maybe wasting someone else's time when they try to maintain the code.
Is the performance savings in using an undocumented feature worth the risk of complicating an upgrade later down the track? Clearly it depends on the performance increase and the application, but I maybe this is difficult to determine until later, when the overall performance and resource usage of the application can be more fairly judged. I'm always very skeptical when I find myself wanting to trade off against future maintenance, because it does often bite me when I do not keep it in the forefront of my mind.
Make sense? I might blog about this issue - If so I will leave a note.