Yes I agree,
I increased the loop count to 5000 and noticed that the StringBuffer method
ran 1/3 to 1/2 quicker than cfset a = a a bit more text, .
However when I tried again with a loop count of 500 StringBuffer method was
slower.
my code:
cfset jsbOutput = CreateObject( java,
Gert Franz wrote:
just change some text to something about 10 times larger and change
the 500 to maybe 5000 and then you'll find out how fast string buffer is
in comparison to CFMX strings...
Neat. I just did 2,000,000 string appends of a 26 character string,
resetting the string to
You can easily eliminate the evaluate() as a factor by replacing
cfset field = evaluate(resultSet.#ThisColumn#)
with
cfset field=resultSet[ThisColumn][resultSet.currentRow]
but it doesn't look like you're executing that line enough times to account for
the performance problem.
Reed
I have
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
You can easily eliminate the evaluate() as a factor by replacing
cfset field = evaluate(resultSet.#ThisColumn#)
with
cfset field=resultSet[ThisColumn][resultSet.currentRow]
but it doesn't look like you're executing that line enough times to
scracth that, your method took 45 seconds, the evalute() method took 50
seconds. That was on a drop of about 2500 records.
Rick
~|
Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting,
up-to-date
scracth that, your method took 45 seconds, the evalute() method took 50
seconds.
The parania about evaluate is strictly a matter of philosophy.
The impact on performance is only marginal.
--
___
REUSE CODE! Use custom tags;
See
I suspect that its your use of Append. Appending to a file means that
everytime the file has to be opened, seeked to the end, and the new value
appended. This is pretty slow if you to it a bunch of times.
I suggest creating the string in memory and then writing it out to file.
Russ
When doing a lot of string concatenation, you should totally use the Java
string buffer:
cfset jsbOutput = CreateObject( java, java.lang.StringBuffer ).Init()
/
cfset jsbOutput.Append( some text ) /
cfset jsbOutput.Append( some text ) /
cfset jsbOutput.Append( some text ) /
cfset
Well you're also building a string by repeatedly appending. This
creates a new string every tiem, assuming cf doesn't optimize code like
that into using stringbuffers.
Also, do you want the 445 KB tyo be sitting in RAM only to write to some
file?
I think you should write some better-performing
Back in June there was a thread called CFFILE Performance about this on
the BlueDragon Interest mailing list that might be helpful to you, Rick. I
know you're a subscriber and that you probably have those emails handy. But
for those who don't, you can search the archives of the list here:
and Information Technology
E-mail: [EMAIL PROTECTED]
-Original Message-
From: Ben Nadel [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 17, 2006 1:07 PM
To: CF-Talk
Subject: RE: Performance problem
When doing a lot of string concatenation, you should totally use
Ben, when would you use java.lang.StringBuffer as compared to
cfset a =
cfloop index=i from=1 to=500
cfset a = a some text
/cfloop
I found the above method faster.
Andrew.
When doing a lot of string concatenation, you should totally use the Java
string buffer:
cfset jsbOutput =
On 12/15/05, Cornillon, Matthieu (Consultant)
[EMAIL PROTECTED] wrote:
1) In the CF Administrator, it seems that you set the client variable
store for the *server* and not for the specific CF application. Is that
correct? In other words, if I have two applications, named
application_one and
People seem to have no end of problems with client variables. One
problem is they are a database hit on every request whether you use them
or not. Another is that bots fill up your database and then weird things
start happening (see my thread yesterday RSS looks ok but not ok). We
found that
December 2005 10:07 a.m.
To: 'cf-talk@houseoffusion.com'
Subject: RE: Performance Problem - Client Variables
People seem to have no end of problems with client variables. One
problem is they are a database hit on every request whether you use them
or not. Another is that bots fill up your database
All,
Thanks for your input on the client variable problem I mentioned. Turns
out that the problem was that the client variable store table (in an
ODBC datasource) was not indexed properly. Never would have tracked
that down if you all hadn't given me the hints that you did. Major
problem
16 matches
Mail list logo
