R. Rajesh Jeba Anbiah left a comment concerned about the performance hit when using the CakePHP Asset Packer Helper.

The major reason for choosing the Asset Helper is to speed up the site. But, the hit on the helper call is heavy–at least for me. [snip] ...for the real benefit, one seems need to manually minify/pack.

I decided to put this to the test. I grabbed a fresh download of the latest CakePHP 1.2-beta and made a basic TestsController with one action with a view. It didn't use a model. I took the default layout and moved it to my /app/views/layouts. In the layout I added 2 Stylesheets and 2 JavaScripts. In the view I included one of each using the $scripts_for_layout method. I used ab, with the parameters "-c 10 -t 60", to do the testing. Since this was all on my local machine network speed isn't really a factor. Essentially I would be getting the times to render the page.

The first test I ran was without the Asset Packer Helper - what you would get with the base CakePHP install.
Here's the baseline results:
Complete requests: 622
Requests per second: 10.36 [#/sec] (mean)

The hope is that including the helper won't hurt these numbers too much. The speed increase gained by using the helper is seen in the download of merged js and css files and since ab is only testing the html file (not the images, css, jss linked within), the benefit of the helper won't be evident in this test.

First I included the helper and commented out the filecaching. This is essentially what happens when the helper is being used for the first time on a particular group of css/js files. Either because one of the files has changed or because the cache hasn't been created yet. Consider this to be the worst case scenario and probably would only really happen a tiny percentage of the time, like right after you do an update. I expected the numbers to take a hit, but not to be this bad:
Complete requests: 32
Requests per second: 0.52 [#/sec] (mean)

Did I emphasize that this scenario doesn't happen very often? I could try to improve this, but I'm not sure it's worth it. This doesn't happen too ofter, plus most of the time is probably in the css and js minifying/packing, which are vendor classes.

Let's take a look at a more common use case. The cached files already exist, so the helper checks to see if there are any changes, finds none and doesn't have to do any extra processing.
Complete requests: 583
Requests per second: 9.69 [#/sec] (mean)

Much better. Still a hit from the baseline numbers, but not too bad.

Here's one more test. In the AssetHelper class there is a var $checkTS. Setting this to false will disable the functionality described above, where the helper will see if any of the original css/js have changed and the cached version needs to be rebuilt. You can safely set this to false if you clean out your packed directories with new builds.
Complete requests: 602
Requests per second: 10.03 [#/sec] (mean)

That's an improvement over the default settings for the helper and are pretty close to the baseline results. The difference is 3.15700 milliseconds/request or .003157 in seconds.

I may look into trying to get that last scenario closer to the baseline, but the difference isn't so significant that I would really worry about it.

So what does the extra .003157 seconds of processing time get you? This isn't a perfect test, but I ran Yslow on the baseline setup and again with the helper. The baseline scored a D(61). With the helper that jumped to a B(81).