Hello again, I dropped out of this conversation as I was busy this morning but I have just run some timings, etc, see below.
Andrew Scott wrote: > > Well I’ll put my hand up as being guilty of using IsDefined(), but > prefer to use cfparam where it really matters. > cfparam is good when you want to create a variable that might or might not exist, the other is useful for testing for the existence only without necessarily creating it. > Why is IsDefined frowned upon though? > The standard train of thought that in most cases you can use structKeyExists() which is faster and is also neater code. I have just finished the timing tests so am not about to go back and throw in some more for IsDefined and structKeyExists to see if there is a difference, that can wait until the next quiet patch :-) but generally it is just that IsDefined is not needed any more as all variables in CF are now in structures where they used not to be so. Following on from the various comments posted here this morning I wrote a test page that did the standard loop-over-the-expression-a-squillion-times thing to get some nice timings and the page had three ways of evaluating two variable names hidden 5 levels down in a massive structure, one being the name of the scope and the other being the name of the variable in that scope. The three were: a straight evaluate() function, one using a near equivalent to the function that Mark suggested and the last version was what we were actually using which was a set of cfif tags directly in the code getting the scope and then a straight structure expression, eg session[the horrible structure value]. The results surprised me a bit, not so much the difference between the versions but the difference between BD6.2 and MX7! The direct evaluate was taken as the reference after the first run of the page (see below) The set of cfif tags were a tad slower for MX7 (1.1 times the time) and about a third slower in BD ie 1.3 times The function version was 3 times slower in MX7 and 4 times slower in BD Ummmm It seems that in that particular context where the variable names being evaluated do not change the evaluate is in fact the fastest! which matches the blog entry I mentioned before. The hardcoded cfif tags are close enough to not make a difference and if the variable names do change so that the parser has to recompile then you will be out in front with the cfif tags. The function was a lot slower, presumably because of the function calling itself as the code within it was almost identical to the cfif version. The one thing we did notice was that the first pass was slower (about twice as long) for the evaluate version but not the other versions so the "compile a mini class" thing does seem to be happening. I agree with Adam, it works as well as anything else and is appropriate in the proper context :-) Kym K --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~----------~----~----~----~------~----~------~--~---
