>> 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.
Right - it's 10 seconds vs 750 *milli*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.
But you have a function call to _set_ each variable, and that function does
far more than reading a single field. So even if the "read" were
significantly faster than a function call (it's not, since you're _actually_
doing a double structure lookup anyway with your notation, which in the end
is just a function call under the hood), you're still calling a function in
order to be able to read the variable. It's just that a "get" or "lazy"
function only reads the necessary data, while the "setAttributes" method not
only sets the variables, but does a loop to boot, over fields which may or
may not be used. The performance of the code illustrates this.
The whole difference in the API is oquery.column.columname vs
oquery.getColumn("columname"). That's not worth 10 times the overhead. Run
some tests with some half-decent sized recordsets and you'll see what I'm
talking about.
I'm not trying to rain on the parade, but this is really about understanding
when it's OK to do something in order to simplify code at the expense of
performance and when it's not.
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]
