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

Budha

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

lbhl

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

你的CPU,SSD很先进，但我仍不相信你所说的！因为从加载几百部词典的速度来看，不是说几十秒，而是几十分钟或者永远卡死，CPU和SSD的硬件提升绝对是不能有任何用处的，除速度能提高几个数量级。
  F% x/ M7 i4 e- F* R
你说的结果只有三种可能：
（1）你将这1000多部词典分了组，实际只加载了少部分；
（2）这1000部词典大都是仅仅有中文释义而无例句和其他解释，内容量非常少
（3）你看到GoldenDict显示出来词典内容就认为它已经不卡了。实际上你拉动一下滚动条或者点击一下打开词典中的任意几部，就会发现根本没反应！

Budha

1.我从来不对词典分组
- m8 S+ y- F8 u- U3 ]" Q+ [& @* o2.我都是把论坛的词典加上去，没有刻意去选哪一类型的词典
3.拉动一下滚动条或者点击一下打开词典中的任意几部，确实有点慢，但不是没反应
- L% H6 D$ a- L, `: W; o
  F: P+ h+ u+ P( b" V- }你可以升级下电脑试试。

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
你得明白，那些动辄装个几百部词典的，有几许是用来学习的

倒也是，23333

medp7060nz

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

zxhoffice

和欧路比较各有优势

lbhl

, q8 s% T) w) Y3 U/ n
词典软件卡究竟是在哪个具体的环节上花费了巨量时间？有人真正细致严肃地研究过这个问题吗？
0 o$ N8 K; g- ^) \
3 k' T% g5 Y9 R1 |# O( `为每一部词典MDX同一个词头构建DOM树加起来的总工作量是最主要的耗时吗？
. L- }' |) L! e屏幕大小和词典窗口大小是很有限的，一屏显示的内容和所有词典同一个词头内容全叠加在一起的整个HTML文档的总内容相比非常渺小。渲染显示屏幕大小那点内容所需要的时间是很有限的，是那些还没有显示出来要拉动滚动条才会出现的内容消耗的DOM树构建时间占据了大部分资源和时间。
) I# F0 B7 i! J1 Z) y
如果只考虑渲染显示完毕之后再点击按钮触发的那部分JS程序（比如默认隐藏中文现在要显示中文），可能无论你编程的JS多复杂，都不会超过每一部词典MDX同一个词头构建DOM树加起来的总工作量，根本不是一个数量级的工作量，无论如何都不会再卡吧？

Castleton

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