> I would be curious if you perform the complete routine if your code runs > slower or faster. Would be good for stream lining the code...
I agree, that would be interesting to see. I think that this test, however, would be more artificial than one that only accessed some of the properties. The reason I say that is because it seems that I rarely use every column in every record that I pull back from the database. > but this > tool is also meant to help the newer CFer who is used to calling > recordsets by saying #rsMyData.myColumn# to use my object like > #objMyData.myColumn# without having to wrap his brain around doing > things yet another way. It would seem that, by using the iterator at all, they would have to learn a new approach. I would think that learning the iterator pattern itself would be a larger hurdle than whether or not they retrieved the value of the column from an object property as opposed to a method. That differentiation *seems* pretty insignificant to me. But, I'm not in a position where I teach or otherwise deal with unseasoned developers regularly so I don't really know. Maybe it's a huge hurdle. :) Regardless, I do understand your point that they will at least be familiar with the ColdFusion way. > Keeping things simple and simular where > possible. There is a performance hit for creating all the variables > every time. (If you call a few MS a performance hit... this tool isn't > meant typically for spanning an entire recordset when CFLoop would do... > so that comparison is void. I'm not sure it is void. You might want to use the iterator pattern to loop over a large results set. You have to, in fact, in ADO. Besides, at what point do you make the distinction between small and large? Most queries do not return a specific number of rows. So, at least some of this is determined at runtime. > This tool is for doing detailed control of a > recordset.) If we are talking about a page that executes in 154 ms > rather than 124... what type of "performance issues" are you getting? The performance counters that were posted earlier were measured in seconds. > Again... this tool isn't just about performance of the server. It's also > about clean and functional code that isn't excessive in performance > cycles. I believe that reading an existing variable is faster than > executing a function call to read each varible. We should test this to confirm it in various usage scenarios. If I get time today, I'll use the latest code you posted with Roland's example (or my own) and see if I can come up with some data to validate this statement one way or the other. > It's not something you > can simplify to the performance of just one function alone without > consideration to how the rest of the code also effects the overall > efficiency. In general, the lazy initialization approach (for lack of a better term), is faster because it doesn't do any work that it doesn't have to do. You bring up a valid point in that, if you have to access every column with each record that you loop over, then the lazy initialization approach gains you nothing (the name collision can be circumvented by using the this.columns.myColumnName approach). However, that seems to be a very specific and, in my opinion, somewhat unrealistic test. I could be wrong, however. That's why we should test these theories. Ben Rogers http://www.c4.net v.508.240.0051 f.508.240.0057 ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
