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

lbhl

以下讨论基于WINDOWS版，安卓版我没试过不能妄评，但估计也差不多。
# E& _4 C7 r' l9 i* ?- Y9 X' ]
+ v6 }0 v& R8 }* fGoldenDict方方面面超越欧路，但有个致命伤：词典稍微一多（比如上百）就卡。
; d: U' D5 T, Z! B0 `# k: }( ]
) G) K) e! \, L# ^4 _0 t经过仔细观察，电子词典软件呈现查询结果页面的速度和安装的词典库数目本身并无直接关系，真正相关的是在每部词典查同一个词获得的查询文字量的总和。需要呈现的文字总量越大它就越慢。如果你装100部英汉词典，但每部词典都是单纯地只有一个中文词解释而无例句和其他解释的，可能不如装20部牛津高阶和朗文当代这种释义及其丰富的词典更卡。查一个意义单纯义项少的所谓“高阶”单词不如查义项多例句多的常用词卡。
) b$ r) p$ |% d
! @) v, |6 A/ F如果不信我的话，请你查几个释义丰富的词看看， 比如 bear take go come, 刚输入完这些词，等他呈现出页面了（你以为此时它稳定了其实根本没完呢）立即用鼠标点击你200个词典中的任意几部词典看看能否立即在词典间随意跳转？保证你卡死不动了。别说SSD了，你就拿DDR4 内存模拟硬盘都没用。这主要是词典软件渲染HTML页面的算法和CPU运算速度的问题。不信的话，它卡在那里的时候，你可以调用任务管理器查看CPU占用率，最高的肯定是这词典软件。
* ^" T0 L! [" @: B7 p欧路在查词结果页面渲染速度上，可以说秒杀 Goldendict，尽管它的速度离我的要求也还很远。

9 m/ _1 a  n1 [( j; ?* Z
$ Q# h& Y: [+ `
要是谁装了200部词典在GoldenDict里（必须有牛津高阶朗文当代等这种释义丰富的词典），能输入常用词之后三五秒之后就能稳定地渲染出页面，且可立即在词典间点击切换无卡顿地随意跳转，请给一个视频作为证明，并给我硬件详细配置，本人愿意附送1万米作为回报！

simonfire

楼主整天就是瞎bb，今天讨论这，明天讨论那，后天是不是要讨论一下单人航天飞机的实现与背后的工程原理？
; ]7 q$ I- k. k, Z* [刚烧开的水是不能喝，用得着大声嚷嚷吗
& \, V) x: n6 {# z  c* L( Y我清是服气透了，你发这些帖子意义何在
! d) t9 E! X+ V7 U, V7 J" q* a

dfliaoyue

照道理说，页面渲染速度和内容多少有关，此外就是css加载、js加载。尤其js的速度，非常考验水平。
何况GD的显示方式是把词典的内容处理后塞到一个html下，查出来时会有先后显示，可见是边渲染边把词典内容往页面html塞。处理速度（处理css、动词条标签）且放一边，DOM操作（就是把内容往html塞这个动作）的速度比js运算慢几个数量级，整多了可不卡么？
这里头应该有逻辑优化的空间。不过估计GD的作者本来也没考虑塞几十个大部头的情况。
: ~! K, D6 d2 A5 E$ ^9 Z3 A* C5 D7 T* V至于你说的要求，我这么说吧：你把那些内容都塞到一个html里，那些css和js都扔到同一个文件夹，你用浏览器打开看看要多久，这就是本身页面的渲染速度。词典软件的渲染速度不会比新版本的主流浏览器快（不然Google/Apple/Microsoft工程师下岗算了），同时还要做别的处理。三五秒时间处理几十上百部内容丰富、有样式有js的词典，光渲染本身就已经超过现阶段浏览器引擎发展水平了。
! q' v- g# d8 v  Q* W0 ?真要快速切换，办法只有说，每个词条单独页面渲染，然后默认全部或多数折叠起来，你点那个再加载哪个。把耗时分散了，自然就“快”了。

我突然想拉屎

/ t( p6 G& [2 A; d. F你说的都对。qt在5.14决定弃用WebKit引擎，而改用WebEngine新引擎。

4 }8 H" j2 b9 f* A6 J3 c% m

Qt 5.14 Qt WebEngine Porting from Qt WebKit to Qt WebEngine

The Qt WebEngine core is based on the Chromium Project

! ]% l+ Y$ n, @& k" Y新引擎是以Chrmium为基础的，渲染超快，排版好。连Edge都不得不低头，以Chrmium为内核了。
4 X$ i4 J  X/ X
1 Q4 H) B6 M2 x5 H, ], I; Q但是GoldenDict这种十年的老古董级别软件，包袱重，很难迅速的从WebKit改成WebEngine， 甚至可能永远不改了。

  c" C) R) s; R你可以去Github区抱怨，让他们重视一下
1 Z; H- z4 T7 ^5 H  l, M

其实，Goldendict在mac下也很难用

可以试试在winehq安装64位绿色版的exe。
我还写了个教程。听说10.15可以用，但只能安装64位。

Jiangxi

词典多的话，分组——能很好解决卡死的问题，我分了好几个组，基本不怎么卡的。

klwo2

1. Goldendict不是国人开发的，你说这么多情绪化语言也没用，作者看不到
7 Q  K6 s+ ^% l+ O  |5 \2. mdict是国人开发的，没有你说的这个问题，也没见你夸

( R, l$ h  X" J8 b
其实，Goldendict在mac下也很难用

atauzki

6 f; H2 [5 N& Y8 l! r" O% d8 P
qtwebkit移植的html浏览器那效率，渲染长文本你还想怎样。
5 ]# E, n1 r- n' F2 k; F% i0 B" wGoldendict就是小开源软件，不满意请自己上去提issue或者提交pr去，别扯什么国外程序员水平。openssl那么多人用，核心开发者才3个
) R$ T/ d6 F, ~# A2 D$ {! G/ r

我爱深蓝

唉，我正是相反，欧路比goldendict慢多了。

lbhl

dfliaoyue 发表于 2019-12-25 21:26
照道理说，页面渲染速度和内容多少有关，此外就是css加载、js加载。尤其js的速度，非常考验水平。
何况GD的 ...

这位朋友您说再多理论也没用啊，反正我这i5的机器，200部词典GD就很卡了，400部死在那什么词也查不了。但人家欧路就是不一样，400多部词典查take go这种几乎解释最多最长的单词也就是最多30秒就稳定结束渲染词典间随意跳转不再卡顿，一般的词10秒之内巍巍泰山般挺立而不倒。
从这点看，欧路比GD强不止是一点半点，就这速度看，洋程序员真该向图程序员取取经了。

lbhl

simonfire 发表于 2019-12-25 21:45
; |' U1 w- @7 @, d4 W: m1 n楼主整天就是瞎bb，今天讨论这，明天讨论那，后天是不是要讨论一下单人航天飞机的实现与背后的工程原理？
...

意义在于有高人能解决此问题。

dfliaoyue

lbhl 发表于 2019-12-25 22:09
: J) q/ Q3 J7 j" k, j( b7 w这位朋友您说再多理论也没用啊，反正我这i5的机器，200部词典GD就很卡了，400部死在那什么词也查不了。但 ...

+ j- W0 C3 _1 j- k5 R欧路是全部显示还是只显示前几本？

lbhl

nonwill 发表于 2019-12-25 21:39
3 o  f* w- X- B3 O% U哈哈，楼主多是站着说话不腰疼。
只是拿CPU占用说说哈，CPU就是拿来用的，密集型任务它不高就说明软件偷懒 ...

朋友你误会了，我写它资源占用率高，是因为前面还有个贴讨论显示速度的都集中在换SSD了以为换硬盘就能解决显示速度。

lbhl

dfliaoyue 发表于 2019-12-25 22:10
欧路是全部显示还是只显示前几本？

4 D  o  x1 y' U当然我是说400多部同时显示了，分组还算啊？当然，一屏放不下，但是我不断切换不同词典无任何卡顿。

dfliaoyue

lbhl 发表于 2019-12-25 22:13
当然我是说400多部同时显示了，分组还算啊？当然，一屏放不下，但是我不断切换不同词典无任何卡顿。 ...

- L% E% e4 B0 j) @/ l$ S( |那应该是分步渲染的。同时渲染不可能怎么快。chrome好像就用这招。
  ~# {8 b$ _! b  P9 u# p' E算法肯定写得好就是。GD的逻辑确实烂，除了渲染之外的开销太大了。我一直期待一个类似移动端mdict那样便捷好用的桌面词典软件，最好是chromium内核。Mdict PC更像个开发调试工具吧，主要是IE兼容模式的内核对html5标准支持稀烂。欧路功能太杂，还总有些诡异的问题，有专业版也不想用。

simonfire

lbhl 发表于 2019-12-25 22:09
, L% F0 W( M% H3 t意义在于有高人能解决此问题。

; p( X9 x( k3 s& E6 \那你应该直接去github提交issue，看看作者怎么说

lgmcw

nonwill 发表于 2019-12-25 22:36
7 i$ U5 i  E8 \8 }/ }都是能提升速度的，只是距要求还有差距，但进步了不是？
今天刚好把GD并发加载词典搞了，我不收藏词典， ...

哈哈哈SSD也没用的，我的NVME 三星970 Pro也不行，字典和主程序都在SSD里，该卡死还是卡死。

lbhl

lgmcw 发表于 2019-12-26 04:43
0 y0 T1 |& t: P/ K8 Z哈哈哈SSD也没用的，我的NVME 三星970 Pro也不行，字典和主程序都在SSD里，该卡死还是卡死。 ...

我说了吧，主要是CPU计算量太大的问题，不是硬盘速度

liuqiuchina

（1）同时大量加载，速度降下来是必然的，个人也希望GD优化后能秒开。（2）就我个人而言，几百部词典同时用的时候貌似不多，把词典按使用场景分组，每个组十几本，几十本，用快捷键快速切换分组，用起来还是很顺畅的。（3）GD是开源，连rasberry Pi都可以正常安装使用，这点是个人喜欢它的硬道理

lgmcw

lbhl 发表于 2019-12-26 09:10
我说了吧，主要是CPU计算量太大的问题，不是硬盘速度

, k9 d. o& e  z7 O: D) Q也不是CPU，就是程序本身的问题。64G内存电脑，8核16线程，超频到4.5GHz，也没用。
0 C. X1 w) l  W0 q2 V. i; ?0 O9 H说白了还是对资源的利用不够aggressive，你看chrome开网页为什么不卡，因为他会想办法捞到最大的资源，完全不考虑节约的，这反而是现代软件最成功的一种优化思路。
我的猜测是：GD的优化思路还是走轻小路线的，做优化是精打细算，词典量小的时候优化极其完备，很容易就能跑起来。但是词典量大了，这种情况就没有考虑没有优化。

lbhl

lgmcw 发表于 2019-12-26 09:35
& j/ u" q4 g$ W2 t: i也不是CPU，就是程序本身的问题。64G内存电脑，8核16线程，超频到4.5GHz，也没用。
说白了还是对资源的利 ...

+ b: G( Y) e0 R3 m3 q2 k: _  _: I( |资源在那不用纯属浪费。我最讨厌那种为了所谓内存和CPU占用率而出卖速度的软件。老子我买了这么好的机器你丫就不用非得老牛拉破车，想气死我吗？你要怕人家资源被你霸占不够用你可以给人家选择小资源运行模式嘛！

lgmcw

lbhl 发表于 2019-12-26 22:24
, b8 g# `+ T8 v  {6 K资源在那不用纯属浪费。我最讨厌那种为了所谓内存和CPU占用率而出卖速度的软件。老子我买了这么好的机器 ...

其实这个也不好做，Adobe lightroom因为跑不满CPU被吐槽了好多年，好在现在追上来了。

gttwork

我分了5个组，常用的有2个组，还是很慢。

nihaocool1980

技术贴，少有。你说的是电脑上装欧路词典吗？

lbhl

nihaocool1980 发表于 2019-12-27 09:59
3 \) H0 E5 m) Z$ U技术贴，少有。你说的是电脑上装欧路词典吗？

* E$ f$ @+ X$ y# H7 k是的，电脑版的欧路。但是估计安卓和苹果的会更差，因为还是INTEL桌面电脑的CPU最强大但都还慢。

dictionaryfan

没多大必要弄上百个词典，分个组，三五本常用的就行