GoldenDict致命伤：HTML渲染巨慢，词典一多就卡，被欧路秒杀!

Budha

我加了1000多本词典都不卡，用的i7 8700cpu,32g dd4 2666内存，再加 nvme 固态硬盘。

lbhl

Budha 发表于 2020-1-26 17:21
0 n7 }3 E% q7 Z1 v2 [6 g3 `9 n我加了1000多本词典都不卡，用的i7 8700cpu,32g dd4 2666内存，再加 nvme 固态硬盘。 ...

你的CPU,SSD很先进，但我仍不相信你所说的！因为从加载几百部词典的速度来看，不是说几十秒，而是几十分钟或者永远卡死，CPU和SSD的硬件提升绝对是不能有任何用处的，除速度能提高几个数量级。

你说的结果只有三种可能：
% a2 k2 I* M  a. C' n5 F（1）你将这1000多部词典分了组，实际只加载了少部分；
（2）这1000部词典大都是仅仅有中文释义而无例句和其他解释，内容量非常少
（3）你看到GoldenDict显示出来词典内容就认为它已经不卡了。实际上你拉动一下滚动条或者点击一下打开词典中的任意几部，就会发现根本没反应！

Budha

1.我从来不对词典分组
/ r0 z& u# d" {2 m" h  j2.我都是把论坛的词典加上去，没有刻意去选哪一类型的词典
3.拉动一下滚动条或者点击一下打开词典中的任意几部，确实有点慢，但不是没反应
6 d( [7 O6 o$ _9 f! C1 Q6 U
你可以升级下电脑试试。

mtaa

1000本词典，每个词条算30kb，光文本就30mb，我这mac chrome都会卡，不说还要解析css和加载js，用的还是qtwebkit这个残废品。

mtaa

欧路windows版，也是用的qt写的吧，不知道是用的qtwebengineview还是cef。cef性能更好些。

mtaa

qtwebkit都快没人维护了，js大点就能把浏览器卡死，用的还是webkit1的单进程模型。

mtaa

mdx的js，css大过200kb就要慎重了，还有pdf直接转的，质量也很差，dom树大的可怕，每个文本都可能用了html标签嵌套。渲染杀手。

我同学

吃瓜，装200部词典也不会全用上吧

我同学

nonwill 发表于 2020-2-7 17:32
你得明白，那些动辄装个几百部词典的，有几许是用来学习的

2 i+ W' B2 D$ N8 m# x$ R- M) ?5 [倒也是，23333

medp7060nz

词典不在多，有几本好的就够用了。

zxhoffice

和欧路比较各有优势

lbhl

- T* x5 Q% c6 W9 w' |& H词典软件卡究竟是在哪个具体的环节上花费了巨量时间？有人真正细致严肃地研究过这个问题吗？

! Q- t; D4 L8 R' o, J' a* I" v+ Q. W为每一部词典MDX同一个词头构建DOM树加起来的总工作量是最主要的耗时吗？
屏幕大小和词典窗口大小是很有限的，一屏显示的内容和所有词典同一个词头内容全叠加在一起的整个HTML文档的总内容相比非常渺小。渲染显示屏幕大小那点内容所需要的时间是很有限的，是那些还没有显示出来要拉动滚动条才会出现的内容消耗的DOM树构建时间占据了大部分资源和时间。

2 T" s- Q% H/ k# x# D3 z$ C如果只考虑渲染显示完毕之后再点击按钮触发的那部分JS程序（比如默认隐藏中文现在要显示中文），可能无论你编程的JS多复杂，都不会超过每一部词典MDX同一个词头构建DOM树加起来的总工作量，根本不是一个数量级的工作量，无论如何都不会再卡吧？

Castleton

欧路也卡，但gd的确难用。