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

Budha

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

lbhl

Budha 发表于 2020-1-26 17:21
我加了1000多本词典都不卡，用的i7 8700cpu,32g dd4 2666内存，再加 nvme 固态硬盘。 ...

$ R3 q. S' u8 U- K1 e! f: a你的CPU,SSD很先进，但我仍不相信你所说的！因为从加载几百部词典的速度来看，不是说几十秒，而是几十分钟或者永远卡死，CPU和SSD的硬件提升绝对是不能有任何用处的，除速度能提高几个数量级。
! d8 d( G: L1 D/ J; l' B0 S
) t0 H5 s2 }& m/ @; Q4 K; A! q你说的结果只有三种可能：
（1）你将这1000多部词典分了组，实际只加载了少部分；
（2）这1000部词典大都是仅仅有中文释义而无例句和其他解释，内容量非常少
5 ^  o5 Z- K* T/ R8 s& `5 p) p. H" B（3）你看到GoldenDict显示出来词典内容就认为它已经不卡了。实际上你拉动一下滚动条或者点击一下打开词典中的任意几部，就会发现根本没反应！

Budha

1.我从来不对词典分组
( {+ i3 h9 L/ w6 ?1 F) |% Q, m4 w2.我都是把论坛的词典加上去，没有刻意去选哪一类型的词典
3.拉动一下滚动条或者点击一下打开词典中的任意几部，确实有点慢，但不是没反应

你可以升级下电脑试试。

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
5 y/ r, H# ~6 s' V; x你得明白，那些动辄装个几百部词典的，有几许是用来学习的

倒也是，23333

medp7060nz

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

zxhoffice

和欧路比较各有优势

lbhl

- m8 Y, {& O. c+ z
词典软件卡究竟是在哪个具体的环节上花费了巨量时间？有人真正细致严肃地研究过这个问题吗？
' n0 d4 |: E/ C* i
1 d' p) V0 F0 ]7 J2 P7 t3 I$ ]: f" J为每一部词典MDX同一个词头构建DOM树加起来的总工作量是最主要的耗时吗？
# H" Q  A- m" G3 D/ a+ |7 z屏幕大小和词典窗口大小是很有限的，一屏显示的内容和所有词典同一个词头内容全叠加在一起的整个HTML文档的总内容相比非常渺小。渲染显示屏幕大小那点内容所需要的时间是很有限的，是那些还没有显示出来要拉动滚动条才会出现的内容消耗的DOM树构建时间占据了大部分资源和时间。
. ~4 I- k1 U5 f
如果只考虑渲染显示完毕之后再点击按钮触发的那部分JS程序（比如默认隐藏中文现在要显示中文），可能无论你编程的JS多复杂，都不会超过每一部词典MDX同一个词头构建DOM树加起来的总工作量，根本不是一个数量级的工作量，无论如何都不会再卡吧？
# {; q! T5 H8 a# j0 S( `7 k

Castleton

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