This content has been marked as final. Show 5 replies
If you only tested it once, you don't have enough data.
These files get compiled the first time you run them.
You should repeat the test multiple times.
Thanks for your reply, but I have actually tested it by refreshing the page many number of times. And the results still come out the same. The cfc call has an overhead of 33%. And most strangely, the time taken by the loop inside the cfc is more than that taken by the loop in the cfinclude (though the loops are exactly identical).
You're not quite testing like for like here, as the function is doing more
work than the include. That said, it should not cause what you're seeing.
Having modified your example to be a like-for-like, I saw the difference
disappear. I didn't expect this, so I dug a bit deeper.
In my modified test I had written the function "properly", making sure all
the variables were VARed and the returntype of the function was specified
and that sort of thing.
So I started to de-factor the changes in my code, bringing it back to your
When I removed the returntype: no difference.
When I removed the VARing: the discrepancy came back.
When I selectively altered the VARing, it seemed to be the i variable that
was causing the performance hit (makes sense, as it's the main player in
the loop, and it's the loop slowing down).
I suspect it's because when the code is compiled, access to public
variables are done via getter methods, which will have some overhead. When
using local variables: they'll be accessed directly.
All the more reason to always VAR one's variables.
Thanks for your excellent insights! Everything makes sense now. From now on, I will never ever miss out putting CFC method-local variables into the var scope.