Firefox启动速度和扩展文件jar格式（zip压缩）是否有关？

一次又一次地讨论这个问题，主要是上次在某个帖子中看到abc@home说，Firefox的扩展都是jar（ZIP）形式存放的，启动Firefox的时候这些zip文件需要解压，浪费了启动时间，我觉得这个说法很有说服力。

当然大家都会推荐用userchromeJS这个扩展来替换一些其它的扩展，但是大部分时间需要对扩展的源代码进行比较深入的研究，例如把扩展解压开再剥离出相关功能，有多麻烦自不待言。

那天随口跟老婆抱怨了一下这个，她倒来了一个很有意思的问题：如果真是这样的话，扩展为什么不以解压状态存放呢？说实在的，压缩成jar文件，省不了多少空间，我现在有20M的扩展文件，压缩形式存放，分析了一下多个扩展的压缩率。结果表明：

[*] 有的扩展都是按Store方式压缩的，如Autopager，也就是说没有应用压缩算法，只是打包。但是打包会让零碎的小文件变得连续，从而节省空间。Autopage节省了大约70% (740K --> 206K)。但更多的扩展，用Store模式，文件大小没有任何变化，节约0%[/*:m]
[*] 有的扩展是有压缩的，如是BetterGreader，用的是Deflate，却只节约了50% （124K --> 63K）[/*:m]
[*] 有的扩展是不压缩的，如Xmarks，扩展的安装目录下根本没有jar文件。[/*:m][/list:u]

现在有一堆问题：

[*] 为什么其它扩展不像Xmarks一样，不打包？[/*:m]
[*] 打包的好处是什么？[/*:m]
[*] 打包的坏处是什么？是不是真的会拖启动速度。如果是，那是像Autopager那样，压缩比例大的扩展拖启动速度，还是无论如何，只要压缩就不可避免地拖启动速度？[/*:m]
[*] 能不能把扩展改成不压缩的形式？[/*:m][/list:u]

欢迎讨论！

首先的问题是有没有一个 Benchmark 工具，让重复的性能测试变得方便而且能够用数字清晰地看出结果？
打包的好处是节省空间，你也说了；同时也减少碎片（更新扩展造成文件改动会产生碎片，文件多了碎片的影响就会叠加）。
另外很多 Java 独立程序都是 jar 打包的，可能这个也是传承的问题，并不是必须的。

这个不太好办
除非扩展不用java写了

我的移动FF所有扩展都是用7Z重新最大ZIP压缩。连EXE、DLL也用UPX和ASPACK压缩，挑压得较小的那个用。
因为公司的是USB1.1老机器，所以相对读文件，解压时间忽略不计。

以上是特例。

但我觉得即使是新机器，硬盘、内存、CPU的速度差异始终存在。

我觉得现在机器瓶颈在磁盘....个人觉得压缩效率高-_-