5 Replies Latest reply on Aug 28, 2008 5:28 AM by codism

    CFC Performance: An Experiment

      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,
        • 1. Re: CFC Performance: An Experiment
          Dan Bracuk Level 5
          If you only tested it once, you don't have enough data.
          • 2. Re: CFC Performance: An Experiment
            fober1 Level 1

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

            - fober
            • 3. Re: CFC Performance: An Experiment
              codism Level 1
              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???
              • 4. Re: CFC Performance: An Experiment
                Level 7

                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.

                • 5. Re: CFC Performance: An Experiment
                  codism Level 1


                  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.