A Strange Issue with CFC Performance

Generally speaking I'm not the first person to complain about performance. My response to performance issues generally is to figure out how well something must perform and then make it fill that need one way or another (often enough with some kind of caching). Which leads me to this article.

A little over a week ago I posted my last article about the potential for using queries as a mechanism for caching content in ColdFusion. The CacheBox project I'm working on is actually more involved than that, being designed to allow the cache to be stored outside the query, but it uses the query as a management tool either way, which makes reporting a lot easier. In my testing the query seemed to perform very well for every operation except the fetch, which was admittedly slower, but after calculating for what I feel are real-world use cases, it seemed even the fetch was reasonably fast enough and there were unquestionable gains in both durability and the performance of all the other operations including the store operation where the query is grown to accommodate new content.

This was great news. So I proceeded to apply this new technique to a couple of CFCs that are going into the CacheBox project. I had actually done a fair amount of ground work on the project by the time I got back to testing its performance and was then met with an odd and somewhat frustrating surprise.

Initially I expected there to be some additional performance cost for wrapping the query in a CFC (or two as the case may be). But I had rather assumed that the basic cost of making method calls on CFCs would be linear. That is to say that I expected the cost of each call to the CFC method to be roughly the same as the last one, irrespective of the number of calls. That didn't turn out to be the case. I was scaling up geometrically as had happened before with the structures. So when making only 100 calls to the store function it executed in about 2.5 seconds (not as fast as I'd have liked), but at only 300 calls to the same function, the cost to execute suddenly spiked to OVER A MINUTE! What?! An increase of 3x volume had produced an increase of 30x the execution cost!

This seemed rather odd to me, as the query had scaled up in a more linear fashion before. So I figured perhaps I had done something wrong in my CFCs. Then it occurred to me that the rather simple (and powerful) ArgumentCollection object we use in ColdFusion is actually a java object under the hood, just like the structure. And in fact, it's behavior is similar to that of a structure, with some additional features. Could it be that creating all those ArgumentCollection objects is what's causing the server to grind down like this?

So I threw together this CFC to test (notice that the method contain no logic, so if there are any performance issues present, they are inherent to the CFC):

Then I ran this loop to see how it scaled up when the only action being performed was calling a method on a CFC.

You can see here that all I'm doing is starting with a small number of method calls and then increasing the number of method calls by roughly 300% on each iteration of the loop. Then I'm calling the method the specified number of times with a couple of arguments and timing the results. (And I made sure that I disabled debugging and robust exceptions in the CF Admin before I tested this, knowing that they can inflate performance costs.)

Here is the end result of that test:

Bam! As I suspected, the basic function calling by itself is scaling up not in a linear fashion like I wanted, but in a geometric fashion like I thought after I started testing.

I have to hand it to Glenn Crocker. Somebody figure out what that guy's drinking, 'cause I want some! He provided an instant solution. And although I could say "that's dumb, that shouldn't be the solution" (because it is, and it shouldn't), right now I'm just happy that it works. :)

The answer?

Put the agent CFC in the application scope.

That's it... just change it to a persistent scope instead of running it in the variables scope of the page.

Instantly when I did that, the performance cost of calling the store method changed to this:

See that? Linear growth. The performance is consistently an average of about 0.1ms per call to the method.

Apparently when you put a CFC in the variables scope and start calling methods on it, it places those method calls in a stack. And of course as the stack grows (even though it ought to grow and shrink in this loop), the performance of the next iteration of the method suffers.

Which reminds me of something else I saw a little while ago about people struggling with a perceived memory leak in ColdFusion (although they never definitively said they had proved it had a leak, merely that they were almost certain). And again, at the time, the issue seemed to be when CFCs were placed into the variables scope of a page instead of being placed in a persistent scope like the application scope and used from there.

I wonder if anyone else has submitted a bug-report to Adobe for this issue? It certainly feels like a bug to me... although I'm not certain the folks at Adobe would classify it that way. Perhaps they're not expecting people to be making hundreds or thousands of method calls in the variables scope of a page? On the other hand there's nothing in the docs that says you shouldn't be able. And given that you can (easily) from the persistent scopes, why not?

Anyway, as a final note, although the request scope has the same performance issue (you can probably guess why), the only thing that's really needed apparently is for the object to start out in the application scope. If you create a pointer to the object in the variables scope, it will still perform fine. So the following code will also be free of the performance issue: