如题，说查询性能可能不严禁，重点应该实在css/js上面吧。我个人对css/js并不在行（能力仅在能够对比修改的水平），还请懂css/js的坛友前来讨论。
特邀：@hua @atauzki @last_idol @johannhuang @endnote @EarthWorm
如下压缩包是我在测试词典库中使用GoldenDict(msvc-x64)查询good的结果页面的导出:
good.zip (12.2 MB)
注：查询过程的完成处理或打开查词结果页面的完成加载的标志是cpu稳定到1%以下，在整个查询过程或页面加载过程中（页面静态文字内容都是很快就展示出来的），cpu单核是100%占用的（4核8线程cpu总体占用12%上下），这个过程大部分时间应该被webkit或chrome核心所占用。
在GoldenDict中整个查询过程 （从提交词条到webkit完成处理）同步处理耗时：5分30秒左右
用Chrome打开附件中的查询结果页面到加载完成（标签不转圈）异步处理耗时：4分钟40秒左右
补充：GoldenDict查询前必须停用取词功能，不然会导致操作系统和其它软件的某些功能卡顿或不响应（应该是系统级别的钩子影响，毕竟goldendict的主线程100%了，系统函数的回调长时间得不到处理），比如Win10开始菜单停止响应， procexp缓慢卡顿，等。
3 个赞
nonwill兄是时候开个新贴了，原来的帖子太长了。
我谈不上懂哈，只是日常用得多，而且喜欢回帖（很多时候只是作为给自己的一个备忘），混了个脸熟。
目前nonwill兄的 goldendict 我用得很满意了，因为不会崩溃非常稳定。
这个我的个人经验是看查询结果与导航面板，里头一出现词典图标就说明查询结束。在此之前我会避免进行鼠标操作。
影响查询速度的感觉主要是js。超过三个以上就开始有滞感？所以新版推出公用的js功能挺有必要，可以减少多个mdx对js的重复使用。我目前还在用划词功能之前的老版本，不知道是否需要在mdx中每个词条保留user.js这个接口才能起用？
另外就是字体，以前老版本当css有过多 @font-face 会导致查询问题，印象中新版本已经作出了改进？
1 个赞
韦传o朗
8
以前知道有些做profiling的工具，比如rational quantify可以分析哪些代码占了多少时间。不知道goldendict是否是用Python写的。网上查了下，python自带profiler。用这类profiling的工具分析对性能问题一目了然。
import cProfile
import re
cProfile.run(‘re.compile(“foo|bar”)’)
另外想提的是个人不喜欢js做得太花哨。对一本词典来说，js就使得性能明显下降了。我们都收集了不少词典了。
hua
11
词库太多，什么浏览器都卡。
Chrome 是每个标签页开一个进程。个人觉得什么在当今MDX词典里面，什么 JS 影响性能都有点扯淡。
要想解决，就采用按需加载。查询结果特别庞大的时候，就加载前十个，每次下滑到底再加载五个。
我觉得还有第三个方案，词典分组。
如果嫌卡，那没必要一下子就显示几十部词典的查询结果，分成两组就会快很多。为了节省一两次鼠标点击而大动干戈改代码，或者研究按需载入是一次5个还是10个，实在不值得。词典分组是个用户可充分自我定制的经济化解决方案。
这么多技术背景差异很大的mdx制作者修改者，要强调规范属实难事。不过，我一直觉得，门槛低才方便不断有新鲜血液加入，是个好事。跟很多开源社区类似，本来就不断有老人退出，已经是个小圈子，没必要过分追求规范。
也许当前还不需要那么强的目的性，从自己感兴趣的玩法出发，侧重例如user.js等自己有热情或者其他能提升自我的方面，反而可能无心插柳柳成荫。
1 个赞
