刚才干了一件吃力不讨好的事情

到了配置文档里面将全部扩展的.jar文件重新封装，在压缩的时候选择“储存”

只有FLASHGOT,SUPERDRAGANDGO这两个扩展大小是一样的（作者也是选择储存）表扬一下，那就是为什么FLASHGOT那么大（包含很多语言包）和超级拖放一个小功能插件也那么大的原因了

那个TABMIX更离谱。。。。选择储存之后，原本大约几十K的变成了几百K（吐血）

ADBLOCK储存之后大小差不多

我只安装了上面三个，理论上虽然大了点，但是读取扩展时候不用解压，应该会提高速度（我的理解是CUP会省一点）
然后我打开FOX的安装目录，发现里面全部.jar都是储存方式保存的（官方这样做，证明应该有用吧）


做完上面那些事之后，打开了dvbbs首页，然后习惯的拖开几个板块

顿时CUP像洪水般升高，吓得整个FOX的脸白了..........


没响应中

呵呵呵呵呵,你的话语真逗!
cpu暴涨的原因可能是里面的算法就是要用到解压，而这段代码可能绕不过去，你如果区是要那样做的话，我建议你去修改一下代码，自己编译！

客游 高升了，恭喜啊！

客游：呵呵呵呵呵,你的话语真逗!
cpu暴涨的原因可能是里面的算法就是要用到解压，而这段代码可能绕不过去，你如果区是要那样做的话，我建议你去修改一下代码，自己编译！回到原帖

不可能～

算法里面用到解压那么FOX里面的.jar要使用“储存”模式吗？

再说了，要解压代码那多麻烦啊？要是我储存这段代码不就不用启用跳过了吗？

现在CPU解压缩几个非常小的zip不费事的啊~~~~~~

打开时应该能省点儿cpu，但是打开速度就不好说了
举个例子1压缩50K，2存储100K
1、硬盘读取50K时间＋内存中解压时间
2、硬盘读取100K时间
个人认为第一种更快些呢

1、硬盘读取50K时间＋内存中解压时间
2、硬盘读取100K时间

个人认为是第二种快，因为硬盘读取的速度肯定比CUP快

cup要换算解压，解压之后也是占用100k，然后FOX再读取

要不就是解压之后形成临时文件然后再读取

呵呵，不赞成楼上观点。现在计算机的瓶颈在I/O子系统。读硬盘和在内存解压，当然是在内存快了~~~~~~~
当然如果想楼上所说的有临时文件生成，写到硬盘上，又从硬盘上读，当然慢了，可能实际上不是这样吧~~~~~
不知道了，等熟悉情况的高手~~~~~~

那么就耗损了内存

要是像tab mix那样选用最佳的储存方式，用winrar解压都要几秒钟


不过好像说.7z或者.zip的格式FOX可以直接读取，不用解压

ccbbs：那么就耗损了内存

要是像tab mix那样选用最佳的储存方式，用winrar解压都要几秒钟


不过好像说.7z或者.zip的格式FOX可以直接读取，不用解压回到原帖

哦，我映像里好像扩展的压缩包就都是.7z或.zip的啊

要是那样的话就是越小越好了