30楼#
发布于:2017-05-29 13:01
白左:Win10 x64, E3-1230v2, RAM 16GB,SSD不知你那个软件的计时标准是什么,我的计时方式和你不一样,不仅仅是感官视觉上的计时,还包括实际的“背后工作”的计时: “我的启动时间计算方法是从启动 Firefox 后看 CPU 占用率从几乎完全占满开始算起,到平静下来几乎完全不占 CPU 为止。” https://www.firefox.net.cn/read-53876-1#read_357402 实际上 Firefox 从启动到界面完全出来后,到能让你操作为止还没太平下来,背后 CPU 仍然还占着很高。我后来还遇到更奇怪的现象是,CPU 占高还分两个阶段:第一阶段是从启动到第一次平静下来,以前就算这么结束了。后来随着版本的升级(包括浏览器版本和各扩展件版本),还会出现第二阶段的 CPU 占高,第一阶段 CPU 占高结束后会平静一段时间,约几十秒,然后会再次出现 CPU 占高,大约十几秒左右。 你们都是 i 什么的 CPU ,SSD 的硬盘当然测不出,只有在低端机器上才能体现出一个软件是否占用资源的好坏。 |
|
31楼#
发布于:2017-05-29 12:12
对,没扩展很快,有扩展会白屏一会才能加载出来
|
|
32楼#
发布于:2017-05-29 12:03
infinity:这是用什么软件录的?回到原帖https://github.com/NickeManarin/ScreenToGif/ 安利一波screentogif,开源,好用,多语言(含简中), 图里自定义毫秒输出的功能还是不久前我提议的,他很快就加入了 |
|
|
33楼#
发布于:2017-05-29 11:47
|
|
34楼#
发布于:2017-05-29 11:46
|
|
35楼#
发布于:2017-05-29 00:40
DOSforever:哈哈,一看你说到 xul ,让我不得不新建配置的就是这玩意儿:崩溃说明某处有问题或不兼容,与XUL技术本身没什么关系…… XUL目前仍然是Firefox的基础技术,虽然在淘汰,但离去除还很远很远。 |
|
36楼#
发布于:2017-05-29 00:38
|
|
37楼#
发布于:2017-05-28 23:21
Win10 x64, E3-1230v2, RAM 16GB,SSD
Fx 54a2 x64(aurora)未开e10s, build config 日用配置3秒见窗口,5秒出页面,8秒全载入,载入时拖动时有点卡 虽然也不够快,但也不至于像楼主那样几分钟吧…… 作为参考,全新配置2秒 日用配置拖慢速度的扩展一个不落(除了ABP换成ubo) fireguesture是真的卡,不过也仅限划手势的时候 tmp在about performance里经常top1但是实际感觉不是很明显 其他的除了拖慢感十分明显,已经被禁用的video download helper以外,没有特别拖慢的,VDH一个的拖慢能力起码相当于下面前五名之和 若是感觉fx慢,多半是因为部分扩展太垃圾的锅,知名扩展大多优化较好,一般不会有明显性能问题 |
|
|
38楼#
发布于:2017-05-28 23:13
|
|
39楼#
发布于:2017-05-28 23:04
|
|
|
40楼#
发布于:2017-05-28 23:01
|
|
41楼#
发布于:2017-05-28 22:47
fang5566:这就是为什么firefox 要开发多进程,取消xul,加入 quantum,都是为了提升性能。否则走原来的老路,ff只会被其他浏览器逐渐抛离。回到原帖哈哈,一看你说到 xul ,让我不得不新建配置的就是这玩意儿: 我原本 IceDragon 启动很慢,于是新建了一个什么也没有的默认 profile ,体验了一下速度快的滋味儿,可再次进入原有的 profile 的时候奇怪的问题出现了,程序报错,具体查看出问题的模块就是 xul.dll 。可原来的 profile 什么也没变啊,就进入了一下默认的 profile ,原配就不让我进了?实在没办法只好重建这个 profile ,然后扩展件一个个装,配置一个个的重设。 |
|
42楼#
发布于:2017-05-28 22:45
我这里旧电脑vivaldi 启动也很慢,也不是所有blink内核启动都快。安装扩展就stylish和ubo。ff启动更慢一点,但没差很多。
|
|
|
43楼#
发布于:2017-05-28 22:41
这就是为什么firefox 要开发多进程,取消xul,加入 quantum,都是为了提升性能。否则走原来的老路,ff只会被其他浏览器逐渐抛离。
|
|
|
44楼#
发布于:2017-05-28 22:37
|
|
|