呵呵，在 firefox 3.1beta3pre 中 JS 打开 JIT 和不打开 JIT 时，我的 List Hunter
抽取器的每页面分析时间都稳定在平均 300 ms 水平（加载和渲染页面除去 web I/O 平均为 300 ms）。在使用 Perl
改写之后，分析 VDOM 的时间为平均 150 ~ 200 ms 的水平（加载 VDOM 的时间为平均 150 ms）。
抱歉,可能还没有完全理解你的List Hunter是怎么工作的,另外VDOM和它是什么关系呢?后面看到了VDOM是自定的格式,那是怎么生成的呢?有没有一个简短的例子,这样比较好理解?
然后这种语言的比较并不公平，因为在 JS 版 List Hunter （还包括其他 Hunter）中，主要时间是在 DOM 操纵上，而非
JS 代码本身。而 Firefox 的 DOM 操纵代价比较高昂[1]。
同意,现在的JS方面也有一些工作使得以后能直接trace into DOM,这样这个瓶颈应该可以被慢慢干掉了,但不是现在.
而在 Perl 环境里，我根据实际需要，对 VDOM.pm 这种
DOM 库进行了优化（但仍是 100% Perl），
难道没有用c的库?
和 Hunter DOM 分析代码之间也不存在很多开销（在 Firefox 里，JS
操纵 C++ DOM 就不同了）。
那我的理解就是:由于JS->DOM的操作慢是瓶颈了?
另外，Perl hunter 仍然依赖于 Firefox[2] 导出带视觉信息的 DOM
（我自己定义了一种很紧凑的基于纯文本的 VDOM 格式），
比较有兴趣知道大概是怎么个格式怎么导出?
而在上面的计时中，并未包含 VDOM 导出的时间[3].
每个element都要去算一遍样式不是比较费时么?是把页面渲染后的DOM文本化么?
按照计划，等这一批纯 Perl 的可脱离 Firefox 运行的 hunter 上线之后，我就要着手 libvdom++
库的开发了，届时一切都是纯 C++，期望届时会有几倍甚至一个数量级的性能提升 :)
Well, 不明白怎么脱离Firefox了,自己分析DOM?
可能我有些背景信息不是很清楚,部分东西没法跟上你了,呵呵
Cheers,
-agentzh
脚注：
[1] 比如 textContent 方法就惊人地慢，同时在标准的 DOM 中，许多视觉信息和 DOM
本身并未融为一体，例如字体、字号、字重、背景色等等，所以在 DOM 操纵中存取这些信息即使自己做缓存也比较吃力。
[2] 事实上，IE 和 Webkit 亦可 ;) 我们已经让 webkit 生成相同格式的 VDOM 输出了 :)
[3] 事实上，在 Firefox 中用 JS 遍历 DOM 生成 VDOM 的开销是比较高的，达到每页面 500 ms
的量级，所以我们已经在尝试使用 C++ 代码来遍历 DOM 以生成 VDOM，特别是在 webkit 中，而非 firefox.
--
>: ~
--~--~---------~--~----~------------~-------~--~----~
您收到此信息是由于您订阅了 Google 论坛"PerlChina Mongers 讨论组"论坛。
要在此论坛发帖，请发电子邮件到 perlchina@googlegroups.com
要退订此论坛，请发邮件至 perlchina+unsubscribe@googlegroups.com
更多选项，请通过 http://groups.google.com/group/perlchina?hl=zh-CN 访问该论坛
-~----------~----~----~----~------~----~------~--~---
博文
没有评论:
发表评论