CFC Performance: An Experiment

[codism]

Hi All,
I was trying to measure the performance overhead of using a CFC versus using a plain cfinclude, and I have come up with some really strange results. I hope someone can throw a light on what is going on.
So basically I made 3 files.
1. testCFC.cfm: This is the file which I run and which either contains a call to the compTest.cfc or includes the compTest.cfm
2. compTest.cfm: This is the included file and contains a simple cfloop doing something
3. compTest.cfc: This is the cfc which contains the same simple cfloop doing something.

I measured the tickcount before the cfc call and after the cfc had returned and I got 210 ms.
When I did the cfinclude I got 150 ms. So it seems that the CFC overhead was 33%. But that seemed unreasonably high, so I measured the time taken to run the loop inside the cfc and that was also 210 ms. Of something is amiss here because the time taken to run the loop should be 150 ms (as in the simple cfinclude).

Am I doing something wring here??

The code for all the files is attached. I would really appreciate if someone could throw a light into this. And any inputs on the performance overheads of using CFC's would be very welcome.

Thanks a lot,
SS

[Dan_Bracuk]

If you only tested it once, you don't have enough data.

[codism]

Dan,
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).

Any ideas???
SS

[fober1]

Hi,

These files get compiled the first time you run them.
You should repeat the test multiple times.

- fober

[Newsgroup_User]

Interesting.

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
version.

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.

--
Adam

[codism]

Adam,

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.

Cheers,
SS