Confirm. CF's type checking happens at runtime, not compile time, and as such it happens on every execution of every function for inputs and returns, always. Compiled languages do it once when the app is compiled and never have to worry about it again. Because "type" has such loose meaning in CF, all "types" are actually resolved by value rather than by, well, the actual "type" of anything. That's how 9 can be a string, a number, or a boolean and a CFC can be resolved by path.from.root.to.Cfc or just Cfc based on the directory structure and the location of, for example, the calling template.
Since the process basically has to figure out what type is expected, then look at the value to determine if it can be coerced into that type, then either proceed or fail, use of types in CF in a production environment can be taxing... however types are handy tools for development purposes. Hence the setting in the administrator to allow people to use types for dev and switch to no types in prod without having to do a lot of regex-based text processing on their codebase. As for whether or not to skip attributes, I suppose it's possible that since missing attributes are just ignored for the purposes of metadata you might get, like, a 10th of a nanosecond better performance, but since metadata is created once per server per class, you really don't gain much in the long run. The performance issues with types is due to the runtime overhead of all the casting and resolving that it must do and not to the simple existance of an attribute. J On Mar 13, 2009, at 3:06 PM 3/13/09, David McGuigan wrote: > I have a vague memory of reading somewhere that when you specify a > return type of "any" or don't specify one at all it improves > performance. That seems pretty in tune with the "disable CFC type > check" setting in the administrator. > > Can some sperts please confirm/deny? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" 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/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
