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