LiveDocs Comments - wtg - public - coding_standards - performance.html

wtg/public/coding_standards/performance.html

SeanCorfield — 2005-12-08T11:45:35

That's a very good point Joshua! Yes, that's a case where correctness outweighs the other concerns being discussed here and it is not immediately obvious that using "is" would cause that problem.

wtg/public/coding_standards/performance.html

jladams97 — 2005-12-02T11:15:27

Unless you are absolutely CERTAIN that the strings you are comparing will never contain leading zeros, you should ALWAYS do string comparisons using Compare() and/or CompareNoCase() not because it is faster than using IS but because it is the only way to truly compare such strings as strings. If you use IS (or EQ) to compare "001" and "0001" you'll be told that the "strings" are the same. I say "strings" because CF is obviously not comparing strings there (else you wouldn't be told those two different strings are the same)--it is obviously comparing numbers. But Compare() and CompareNoCase() always compare actual strings.

wtg/public/coding_standards/performance.html

SeanCorfield — 2004-12-03T15:18:40

Yes, I guess these recommendations apply to cfscript as well but frankly I wouldn't worry too much about low-level optimization like this. Read the introductory section at the top of this page about algorithmic improvements and caching.

For example, I use 'is not' rather than 'compareNoCase()' because 'is not' is much easier to read - and readability is far more important than very minor improvements in performance.

wtg/public/coding_standards/performance.html

Amalaan — 2004-12-01T12:50:28

Sorry, should have added "where relevant" to my post above. I'm aware that CF Script is only a subset of CFML.

wtg/public/coding_standards/performance.html

Amalaan — 2004-12-01T12:17:01

Hi,
Do the above guidelines also apply to CF Script? Can we assume that whatever advice is given re CFML also applies to CF Script?

wtg/public/coding_standards/performance.html

SeanCorfield — 2004-05-08T14:45:46

On low-traffic sites you probably won't notice much of a performance difference and, of course, a lot depends on whether you read the WDDX once and cache the data or whether you read it on each request.

As for embedding CF code in the 'labels', you'll still need the evaluate(DE()) trick with the include file. Don't forget that if your label has " or ' in it you'll need to escape it (double the quote):
<cfset myLabel = "This is a ""string"" in a label"/>

wtg/public/coding_standards/performance.html

McGarnagle — 2004-05-04T07:00:02

I've created a custom tag that uses WDDX for hardcoded data. It reads a wddx-serialized struct that contains english and french text elements for a page. I've not seen any major performance hits... on average, the processing time takes between 15 and 30 ms. How much of a reduction could I expect if I switched to the cfinclude approach?