有哪些因素影响了查询性能?

如题,说查询性能可能不严禁,重点应该实在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 Likes

虽然俺啥也看不懂,但是还是要顶 :smile:

nonwill兄是时候开个新贴了,原来的帖子太长了。

我谈不上懂哈,只是日常用得多,而且喜欢回帖(很多时候只是作为给自己的一个备忘),混了个脸熟。

目前nonwill兄的 goldendict 我用得很满意了,因为不会崩溃非常稳定。

这个我的个人经验是看查询结果与导航面板,里头一出现词典图标就说明查询结束。在此之前我会避免进行鼠标操作。

影响查询速度的感觉主要是js。超过三个以上就开始有滞感?所以新版推出公用的js功能挺有必要,可以减少多个mdx对js的重复使用。我目前还在用划词功能之前的老版本,不知道是否需要在mdx中每个词条保留user.js这个接口才能起用?

另外就是字体,以前老版本当css有过多 @font-face 会导致查询问题,印象中新版本已经作出了改进?

1 Like

问题就是 词库的JavaScript(很小可能是CSS)写的太糟糕,这就是浏览器加载html的逻辑,没办法。

1 Like

另外,蟹邀!
问题是词库太多,拼接的html太大,引用的外在资源太多。批评词库制作者不专业吧。词典层面无法解决,因为web标准直接导致上面长时间加载的结果。

以前知道有些做profiling的工具,比如rational quantify可以分析哪些代码占了多少时间。不知道goldendict是否是用Python写的。网上查了下,python自带profiler。用这类profiling的工具分析对性能问题一目了然。
import cProfile
import re
cProfile.run(‘re.compile(“foo|bar”)’)

另外想提的是个人不喜欢js做得太花哨。对一本词典来说,js就使得性能明显下降了。我们都收集了不少词典了。

不知道有没有这样一种可能,在扫描词典结束后,把所有的js都统一处理合并成一个js。在查询的时候,只加载合并后的js,这样会不会能提高效率?

词库太多,什么浏览器都卡。
Chrome 是每个标签页开一个进程。个人觉得什么在当今MDX词典里面,什么 JS 影响性能都有点扯淡。
要想解决,就采用按需加载。查询结果特别庞大的时候,就加载前十个,每次下滑到底再加载五个。

我觉得还有第三个方案,词典分组。
如果嫌卡,那没必要一下子就显示几十部词典的查询结果,分成两组就会快很多。为了节省一两次鼠标点击而大动干戈改代码,或者研究按需载入是一次5个还是10个,实在不值得。词典分组是个用户可充分自我定制的经济化解决方案。

这么多技术背景差异很大的mdx制作者修改者,要强调规范属实难事。不过,我一直觉得,门槛低才方便不断有新鲜血液加入,是个好事。跟很多开源社区类似,本来就不断有老人退出,已经是个小圈子,没必要过分追求规范。

也许当前还不需要那么强的目的性,从自己感兴趣的玩法出发,侧重例如user.js等自己有热情或者其他能提升自我的方面,反而可能无心插柳柳成荫。

1 Like

你这说法有点暴露自己是前端外行的样子哦。理解这个问题,你得理解浏览器内核渲染网页的逻辑。这东西,在词典论坛讨论就有点跑题了。PS:浏览器内核网页渲染逻辑,很多初级前端开发者都并不了解。

我啥都不知道~