php_speedy，对付那些包含多个js脚本和css资源的页面，在代码输出到浏览器前，分析代码，找出所有js脚本，合并、压缩（最小化、gzip）；找出所有css脚本（合并、最小化、gzip)；对生成的源码html进行最小化、压缩（据观察，gougou.com为代表的一些站点已经非常重视包括html代码的精简了）。

那么，思路非常优秀，且，只需将资源全路径、资源时间拼合，即可形成唯一文件缓存，且可给此文件加过期时间。特别值得一提的是，文件名由三大部分决定：
md5(     implode("_",$script_array)    .    $datestring    .    implode("_",$options)    )
原资源位置     原资源日期     php_speedy配置参数数组

实际工作中碰到没有精力去人工处理js、css代码的情况实在太多，那么，此软件恐怕会有相对广泛的应用。
——恰恰在面对这种多js及多css的环境时，php_speedy会造成严重的性能问题：在实际测试时，一段110ms的系统加php_speedy正常情况下为140ms，偶尔会被php_speedy变成4,500ms，这非常恐怖（我们的目标是这样的情况仅因为生成js和css合并码而发生一次，并且效率尽可能高）。

kolidon经过一个多小时奋战，初步实现了性能调优，根据以下四个原则：
1) php_speedy首先会需要分析源码，这个扫描使用正则表达式，时间未知（待测定能用情况）；
2) 其次，它会需要合并多js文件，而在需要使用php_speedy的条件下，文件往往会多、大、杂（若有精力去去除js文件中的非关键部分，也用不着php_speedy了），那么，php_speedy的字符串合并和去空格等操作，会杀掉30-40ms的时间；
3) 探测同命文件是否存在，若不存在，生成文件，有个大问题是，在生成文件后，往往会将缓存文件夹中的其他文件删除，因为它会认为旧文件已经过期——这种情况在更改原始js或css文件时确实可能发生，但问题是，一旦更改原始文件，文件名即已不同，另一个情况是，站点的不同页面生成不同的脚本或css资源引用又当如何？
4) 再一个是，生成的缓存文件竟然是php代码（包含代码头部及所有js或css拼合码）这意味着每一次请求，这段php段码都需要生成http头设置过期时间，然后自身的剩余部分输出（最大的性能问题其实在这儿！）

性能有极大提升，典型的时间可在10ms消耗（虽然仍然很巨大，但对普通应用来说足够了）。但仍然有意外情况下时间会较长。其中正则表达式匹配js和css这一块并未优化，但这一块应该不能解决时间过长这个问题。

不管如何，总算可用了。

补记：偶尔性能低的原因使用xdebug profiling功能已解决，略过了几处语句。