firefox浏览大量js的页面很卡，有没有什么有效的改进方法

Adbear

关注中，我的FF也是速度不快：（

viogus

pgo是种优化编译的方法，简单的说就是编译两次，第一次编译就是普通的编译，第二次编译就是用前面的编译结果得到的profile来优化，详细的看MDC的东东，我以前在windows下编译过，linux下，屈服于portage，没试过
https://developer.mozilla.org/en ... Guided_Optimization

viogus

另，3.1beta1已经挺稳定了，可以试试，js的执行速度提升很多

jarryson

有这么夸张么，我这里ff浏览js多的页面比opera好的多。cpu占用是有点高就是了

zxuan

我的use和lz有些小区别
net-libs/xulrunner-1.9.0.4-r1  USE="custom-optimization dbus gnome java startup-notification -ipv6"

www-client/mozilla-firefox-3.0.4  USE="custom-optimization dbus gnome java mozdevelop startup-notification xulrunner -bindist -iceweasel -ipv6 -restrict-javascript"

lejcey

　　试了一下 GCC PGO，说不定是个很有用的优化方法，只是要重复编译，对于Gentoo来说，重新编译系统恐怕是个噩梦，而且不知道potage会把profile保存在什么地方。

　　源文件 : www.cowell-shah.com/research/benchmark/code/benchmark.cpp

　　这个源文件不支持C＋＋标准，无过通过GCC，还有一些小错误，所以我改动了一下，其他什么地方都没动，文件的输出原来是“C:\\TestC.txt”，我也改了。

1. #include <ctime>
2. #include <cmath>
3. #include <cstdio>
4. using namespace std;
6. ......
8. [19]        long long longMin = 10000000000LL; // 10B
9. [20]        long long longMax = 11000000000LL; // 11B
11. ......
13. [158]        stream = fopen("TestC.txt", "w");
15. ......
17. [167]        stream = fopen("TestC.txt", "r");

复制代码

1. $ g++ -march=core2 -O2 -pipe -w

复制代码

Total elapsed time: 19040 ms

1. $ g++ -march=core2 -O2 -fprofile-generate -pipe -w

复制代码

Total elapsed time: 23580 ms

1. $ g++ -march=core2 -O2 -fprofile-use -pipe -w

复制代码

Total elapsed time: 18830 ms

　　这样一个小程序有了些许的提升（1%?），但是-fprofile-generate会造成性能大幅下降，我想这个功能用在多媒体上效果会比较好。比如x264的编码解码，应该会有一些提升。不过x264很多代码已经是汇编了，估计效果也不大，现在我已经开始怀疑Gentoo的“高效”了，恐怕在更多的时候我们自己编译的代码远不如官方的，仅仅是编译参数的不同。我认为Gentoo最大的魅力在于“定制”，我曾经在win系统下自己编译了x264的编码器，用的VC2005，结果比官方编译的性能下降了很多，官方可以达到45fps，而我的只能达到30多fps，并且进程不能完全利用CPU（最多只80%）。一方面恐怕也是MSVC编译器比较菜吧，换ICC又只能编译无法连接。

woodenapple

lejcey说的有道理.其实我相信在gentoo的机制下面可以创造出完美的系统,编译出比官方的binary更好的程序.但是有个问题就是我们不可能都是编译器专家,并且深入了解每个程序各自的特点而针对每个程序进行不同的编译器优化.
     我个人感觉gpo也是一个基于统计的一种优化方式,不说比较麻烦(编译一次就够呛了,两次:yun,而且应该也不可能达到理想化的优化性能.也许对于我这种不喜欢反复琢磨的懒人来说,使用binary的效果说不定更好.确实我用firefox-bin速度更稳定一些.但是说到底,一般的程序,靠编译优化的性能提升应该还是比较有限,我相信更多的问题在于程序算法本身.
     但是我还是感觉我实验室ff慢的原因不仅仅是编译优化的问题.家里的电脑(gentoo on amd2500++512M+MX440)跑ff都比我实验室的(gentoo on 酷睿 +1G+GMA945)快,同样的没怎么优化,这没法说得过去.


现在我怀疑是不是显卡的问题.945板载显卡,以前都是使用i810的驱动,跑beryl飞一样.现在xorg换成vf86-video-intel,好像是intel自己的驱动,拖动窗口都有很明显的残影
另外

2. applepie crazyapple # eselect opengl list
3. Available OpenGL implementations:
4.   [1]   xorg-x11 *

复制代码

我还真没注意过,这个opengl是不是有问题,intel自己的驱动那

woodenapple

又看了一下,确实用的是intel的驱动,2.5.1,xorg的log里面也写着加载了这个模块.但是opengl只有一个xorg-x11,没得选

xiaorui

可以屏蔽一些吧。很多js都不是我们需要的。广告的js太多。

lejcey

Post by woodenapple;1914618
lejcey说的有道理.其实我相信在gentoo的机制下面可以创造出完美的系统,编译出比官方的binary更好的程序.但是有个问题就是我们不可能都是编译器专家,并且深入了解每个程序各自的特点而针对每个程序进行不同的编译器优化.
我个人感觉gpo也是一个基于统计的一种优化方式,不说比较麻烦(编译一次就够呛了,两次:yun,而且应该也不可能达到理想化的优化性能.也许对于我这种不喜欢反复琢磨的懒人来说,使用binary的效果说不定更好.确实我用firefox-bin速度更稳定一些.但是说到底,一般的程序,靠编译优化的性能提升应该还是比较有限,我相信更多的问题在于程序算法本身.
但是我还是感觉我实验室ff慢的原因不仅仅是编译优化的问题.家里的电脑(gentoo on amd2500++512M+MX440)跑ff都比我实验室的(gentoo on 酷睿 +1G+GMA945)快,同样的没怎么优化,这没法说得过去.


现在我怀疑是不是显卡的问题.945板载显卡,以前都是使用i810的驱动,跑beryl飞一样.现在xorg换成vf86-video-intel,好像是intel自己的驱动,拖动窗口都有很明显的残影
另外

1. 
   
2. applepie crazyapple # eselect opengl list
   
3. Available OpenGL implementations:
   
4.   [1]   xorg-x11 *
   

复制代码

我还真没注意过,这个opengl是不是有问题,intel自己的驱动那

　　我认为您说得很有道理，其实现在很多程序都有了自动检测CPU的代码，尤其是密集计算型程序，比如游戏、多媒体、数学软件，会根据不同的CPU自动启用一些指令集，达到更快速的目的。

　　对于x86体系，为了兼容旧CPU，几乎所有的程序默认都是-march=i686的，我还没有测试仅仅是将march换成core2会不会得到直接的性能提升。对于x86_64来说，桌面64bit芯片出来的时候似乎就带了sse2指令集？所以恐怕很多人认为64位系统比32位系统快的原因就是这一点？所以我觉得Gentoo对于x86体系自己编译应该是有不少提升的。我在编译内核的时候将参数改为-O3 -march=core2 -fomit-frame-pointer -s，使用这个参数系统并没有出现任何不稳定的情况，在启动的时候，启动到OpenRC之前的时间从5.1秒减少为4.8秒，而且FrameBuffer的速度飞快，似乎只是一个微小提升，不过kernel和glibc的微小提升对系统就是一个大幅提升。

　　我觉得现在系统的主要瓶颈不在CPU上，而在于硬盘的速度，基本上CPU的速度每2年可以翻一番，但是硬盘的速度在过去4年以来只翻了一番，所以我在思考，是不是在非密集型计算的程序上将代码编译成-Os会更快呢？减少程序加载的时间。大多数程序加载之后驻留在内存中，并不会需要太多的CPU资源，而大部分性能都损失在加载的过程当中，尤其是TeX这类程序，真希望TeX能将那几万个小文件打包一下。

　　至于您说的驱动，我不是很了解，因为我没有笔记本，也不知道集成显卡怎么设置，通常我在安装了nvidia的驱动之后就可以选择nvidia来渲染了。