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

Budha · 发表于 2020-1-26 17:21:05

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

lbhl · 发表于 2020-1-28 17:40:32

Budha 发表于 2020-1-26 17:21 ^. Y' D& ]$ |5 B7 j# A
我加了1000多本词典都不卡，用的i7 8700cpu,32g dd4 2666内存，再加 nvme 固态硬盘。 ...

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

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

Budha · 发表于 2020-1-28 21:35:58

1.我从来不对词典分组
2.我都是把论坛的词典加上去，没有刻意去选哪一类型的词典
3.拉动一下滚动条或者点击一下打开词典中的任意几部，确实有点慢，但不是没反应

你可以升级下电脑试试。

mtaa · 发表于 2020-2-1 00:30:41

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

mtaa · 发表于 2020-2-1 00:34:02

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

mtaa · 发表于 2020-2-1 04:19:01

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

mtaa · 发表于 2020-2-1 04:37:02

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

我同学 · 发表于 2020-2-7 14:21:38

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

我同学 · 发表于 2020-2-8 01:24:42

nonwill 发表于 2020-2-7 17:32" D l z1 x) ^9 ?/ U) r! ]5 a8 @
你得明白，那些动辄装个几百部词典的，有几许是用来学习的

倒也是，23333

medp7060nz · 发表于 2020-2-14 04:36:34

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

zxhoffice · 发表于 2020-3-19 15:30:40

和欧路比较各有优势

lbhl · 发表于 2020-3-26 12:42:18

本帖最后由 lbhl 于 2020-3-26 14:07 编辑

词典软件卡究竟是在哪个具体的环节上花费了巨量时间？有人真正细致严肃地研究过这个问题吗？

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

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

Castleton · 发表于 2020-3-26 14:48:32

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

		自动登录	找回密码
密码			免费注册

[经验交流] GoldenDict致命伤：HTML渲染巨慢，词典一多就卡，被欧路秒杀!