rust开启优化后, 与C没差别了, 都很快:

编译器 优化 时间
gcc -- real:0m3.930s, user:0m3.916s, sys:0m0.008s
gcc -O1 real:0m0.630s, user:0m0.624s, sys:0m0.000s
gcc -O2 real:0m0.002s, user:0m0.000s, sys:0m0.000s
rustc -- real:0m4.172s, user:0m4.000s, sys:0m0.020s
rustc --opt-level=1 real:0m0.003s, user:0m0.000s, sys:0m0.000s

gcc 的版本是4.9.1
rust版本是0.12

源代码:
[code]
$ cat sum.c
#include <stdio.h>

int main(int argc, char *argv[]) {

long i = 0;
long s = 0;
long limit = 1000000000;
while (i < limit) {
s = s + i;
i = i + 1;
}
printf("%ld\n", s);

return 0;
}
[/code]
[code]
$ cat sum.rs

fn main() {
let mut i = 0i64;
let mut s = 0i64;
let limit = 1000000000i64;
while i < limit {
s = s + i;
i = i + 1;
}
println!("{}", s);
}
[/code]

Qt, Gtk用的都是MVC结构的设计, 并且Gtk用MVC更彻底, 比如GtkScale等, 都是MVC的, 而Qt却不全是.

如你所说, Qt只处理被显示的那部分数据, 可Gtk不同, 每一次向GtkListStore中插入条目时, liststore.append(...), 它都会先对之前的条目做一些检查之类的工作(GtkTreePath?), 并且还有一些其它操作(这个我还没来的及读源码, 但在mail-list中有人提出来), 也是很繁琐的; 而且, Gtk默认情况下, 是在等所有数据都插入到ListStore之后, 才会显示出来, 然后才能接受用户的操作, 这种设计在数据非常多时, 就有严重的性能问题了.

另外, 关于gtk的性能问题, 不晓得有没有人用过glade(GUI的设计工具), 当在glade中编辑一些widget时, 比如GtkTreeView 向里面加入新的TreeViewColumn/CellRenderer时, 会特别慢, 并且CPU很会跑的很高(70%左右, 在我笔记本上), 通常, 右键, 加入一个新的CellRenderer时, 可以先吃一口苹果, 或者喝口水, 之后这个新的CellRenderer才被创建出来. 这个性能问题, 在glade2中就有存在, 也有一些人在glade的mailing list中反映, 可到现在glade3.15了, 还是依然存在.
相反的, Qt的designer就不存在类似的问题. 这里是一些提升GtkTreeView性能的一些小技巧, http://faq.pygtk.org/index.py?file=faq13.043.htp&req=show

当然, 我并不愿意来黑gtk. 我是很喜欢用这个GUI toolkit的. 也用它写了一打软件, 可是, 在开发这些软件的过程中, 确实发现了gtk存在的一些问题.

话又说回来了, Qt也是存在很多问题的, 与Gtk相比的话, 比如QSetting很明显不如GSetting好用, 后者是非常统一的, 实现了类似windows下的注册表的功能, 这样的话, 修改配置变得非常容易了; 而QSetting(在linux平台, 当然在windows平台, QSetting是用的注册表), 只是用ini格式的文件保存一下配置而已, 这样的话, 就很难被其它软件修改了. 举个例子, Gnome的壁纸, 其设置信息是用GSetting保存起来的, 我们只需要在其它程序中调用gsetting的API, 就可以修改gnome的壁纸了, 而不用理会这些设置是用的什么格式.


最后, 是广告环节, 有朋友写的酷我音乐盒的linux桌面客户端, 用的就是python/gtk的框架, 各位不妨试用一下.https://github.com/LiuLang/kwplayer

我去, 刚发的贴子里面有错字, 多打了一笔, '载'写成了'截'. v2ex为何不可以修改之前的贴子? 好纠结 ->||<-

慢的原因:
ubuntu 默认的文件管理器(ubnity/gnome桌面中用的是这个, KDE环境中默认的是dolphin)是nautilus. 它使用了gtk3 的GtkIconView, gtk有一个缺陷就是在GtkListStore(GtkIconView的model)载入数以千计条的数据时, 会非常慢, 更慢的是, 要载入的数据中包含图标. 如果你的那个目录里包含了大量的图片, nautilus会默认启用图片预览功能, 那会更加缓慢. 慢, 是gtk框架本身的设计问题, 当然这个问题可以在写程序时用一些技巧来避免.

解决方案:
1.给nautilus打补丁, 使用lazy loading技术, 就像在网页中载入大量图片那样的. 当滚动条向下滚动时, 才截入接下来要显示的内容, 这个比较容易实现; 或者也可以加入后台自动截入的功能, 先显示前一部分, 后面的再一批批地加载.

2.或者换用Qt系列的文件管理器(dolphin之类的), Qt在ListView, TreeView等方面做的优化比gtk的要好, 速度也更快. 之前我测试的数据显示, 载入同样的数据(估计有10K条sql记录), 感觉qt比gtk快了有10倍, 并且qt的在滚动时还更顺畅. 我不是在黑gtk, 但性能方面, 这确实是gtk本身设计的不足, 可以搜索一下 gtk liststore performance, 这个问题已经存大数年了, 仍然没有被修复.

3. 或者最简单的, 关闭nautilus的preview功能; 用treeview来显示(而不是默认的IconView); 减少要显示的条目, 比如只显示filename, date等少数类信息. 这样设置的话性能会有所提升.

另外, 能问一下你为什么要这么做吗? 好玩? 数据量大的话果断用终端呀. ls | less 或者 ls | grep也不慢.

@kehr 不客气. 设计界面时有遇到什么问题了, 可以随时找我探讨, 大家共同进步嘛.[email][email protected][/email]

真实的情况是, 我为了回答你这个问题, 才注册的v2ex帐号.