如题,说查询性能可能不严禁,重点应该实在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
nonwill兄是时候开个新贴了,原来的帖子太长了。
我谈不上懂哈,只是日常用得多,而且喜欢回帖(很多时候只是作为给自己的一个备忘),混了个脸熟。
目前nonwill兄的 goldendict 我用得很满意了,因为不会崩溃非常稳定。
这个我的个人经验是看查询结果与导航面板,里头一出现词典图标就说明查询结束。在此之前我会避免进行鼠标操作。
影响查询速度的感觉主要是js。超过三个以上就开始有滞感?所以新版推出公用的js功能挺有必要,可以减少多个mdx对js的重复使用。我目前还在用划词功能之前的老版本,不知道是否需要在mdx中每个词条保留user.js这个接口才能起用?
另外就是字体,以前老版本当css有过多 @font-face 会导致查询问题,印象中新版本已经作出了改进?
1 Like
韦传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 Like