It seems like the "move" methods should throw errors if they are asked to
perform an invalid operation. ADO throws an "out of bounds" error, if memory
serves.
I think various Java record set objects (I'm no Java programmer) function
similar to your code, allowing for the following short cut:
<cfloop condition="#iterator.moveNext()#">
...
</cfloop>
As opposed to the ADO style:
<cfloop condition="#iterator.hasNext()#">
...
<cfset interator.moveNext()>
</cfloop>
I prefer the ADO method myself because 1) it's not tricky (I hate tricky
stuff); 2) methods do one and only one thing, returning values when they
should return values; 3) currentRow does not have to start out in an invalid
position. By way of explanation, using the short cut method, the currentRow
has to be initialized to 0, otherwise, the first call to iterator.moveNext()
will increment the currentRow to 2 before the first record is processed.
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 12:46 PM
> To: [email protected]
> Subject: RE: [CFCDev] query object CFC Beta
>
> John, et all,
>
> Let me know if this version makes it.
>
> I understand the cleaner code argument, but it's really not worth
> sacrificing _that much_ performance just for the sake of having "fields"
> on
> the object. You're also really violating encapsulation rules since you're
> changing the object definition at runtime.
>
> With only minor modifications, the attached version runs on average 10x
> faster than your original. Also, having a getColumn("columnname") more
> closely resembles java/.net and is also a ton more performant. Here's the
> difference in "real" code:
>
> myQuery.column.myColum vs myQuery.getColumn("myColumn")
>
> It's really not appreciably more difficult to read. In fact, I'd argue
> it's
> even clearer what's going on.
>
> Also, I know you like the "var local = StructNew()" style coding, but
> you're
> _really_ burning yourself performance-wise in the moveNext, movePosition,
> and movePrevious functions. Think about it - you're creating a structure
> for *every record in the query*. That's expensive.
>
> I know this is targeted at beginners, but that's exactly why it should
> perform as best as possible. Beginners are far more likely to write slow
> code to begin with, so why compound their problems? It will only serve to
> frustrate them when their code runs dog-slow.
>
> Roland
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of John Farrar
> Sent: Thursday, February 24, 2005 11:37 AM
> To: [email protected]
> Subject: Re: [CFCDev] query object CFC Beta
>
> Well... didn't get it.
>
> Curious... your performance cut... that would have to include the call
> to read all the attributes....
>
> Total Performance test.
>
> Caller Code Test..
> .
> start...
> create object and run init function
> move record
> read all columns
> end
>
> 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... 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. 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. 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?
>
> 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. 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.
>
> Thanks,
>
> John Farrar
>
> Roland Collins wrote:
>
> >Ben,
> >
> >These are exactly the reasons for my suggestions last night :) Did my
> >revised version of the CFC make it to the list around 10:40-ish?
> Sometimes
> >they get dropped. It has your suggestions incorporated, and some
> >performance tuning that cuts the iteration time to about 10% of the
> >original.
> >
> >Roland
> >
> >
>
>
>
> ----------------------------------------------------------
> 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]
