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]
QueryIterator2.cfc
Description: Binary data
