Roland, thank you very much for taking the time to do this. The performance trade off is greater than what I expected. I can't imagine a situation in which the oquery method would make up the difference.
Ben Rogers http://www.c4.net v.508.240.0051 f.508.240.0057 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Roland Collins > Sent: Thursday, February 24, 2005 2:25 PM > To: [email protected] > Subject: RE: [CFCDev] query object CFC Beta > > 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] ---------------------------------------------------------- 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]
