Here's some performance testing with various size recordsets, in seconds. Also attached is a graph of the average performance and the test script used. I think this demonstrates that the trade off for having "property" style notation vs. having getColumn() style is clearly not worth the performance hit.
Run # Record Count oquery QueryIterator2 1 100 0.100 0.050 2 100 0.111 0.030 3 100 0.110 0.030 4 1,000 0.570 0.061 5 1,000 0.561 0.060 6 1,000 0.471 0.080 7 5,000 1.442 0.300 8 5,000 1.802 0.341 9 5,000 2.153 0.340 10 10,000 2.744 0.711 11 10,000 3.625 0.541 12 10,000 3.184 0.521 13 15,000 4.547 0.841 14 15,000 4.887 0.781 15 15,000 4.035 0.802 16 20,000 5.518 1.222 17 20,000 6.670 1.141 18 20,000 6.029 1.091 19 25,000 6.920 1.472 20 25,000 7.120 1.302 21 25,000 6.980 1.352 Roland -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Rogers Sent: Thursday, February 24, 2005 12:51 PM To: [email protected] Subject: RE: [CFCDev] query object CFC Beta > 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] ---------------------------------------------------------- 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]
test.cfm
Description: Binary data
<<attachment: query-perf.gif>>
