最近发布的GoldenDict++中禁用了个别特性 — 主要是早期为支持对词典内容的视频播放所做的部分实现，没想会收到学友反馈程序的查询速度变快了，这是我预料之外的。
压马路时候思考了一下，与视频播放支持相关的实现大致为两处：编译期预定义的参数影响了程序内的默认 mutex 的封装，其实也就是在C++11的内置 mutex 上的简单包装（最初的实现基于Qt Api），另一处就是使用正则在HTML代码中的替换处理。
实现对词典内容中HTML标签 source 和 embed 等的支持，需要在用户查询过程中完成对视频内容的文件缓存处理，并替换内容源码中的视频链接为本地缓存的文件。
当时只是为了能够快速且以尽可能少的侵入性修改来完成这一支持，实现特别的简单，但显然违反了原有的数据访问的排他性设计 — 带有视频标签的词典资源的读取导致了资源访问线程死锁。为了解决死锁问题，也只是简单的将原来的 std::mutex 替换为递归锁 std::recursive_mutex。
只一行代码就解决了死锁的问题。随这一行代码，加上对HTML内容的正则处理多加了几个标签，性能下降肯定是会有的，但对查询用的总时间不会有很明显的影响 — 在用户体验上应是可被忽略的。
对词条释义内容的读是异步多线程的（一词典至少一个读线程，除个别如EPWing格式，不同词典的线程间并无互通数据），但只有一个用户线程来组织（处理）这些数据，读线程结束前通知用户线程，用户线程将释义内容依词典分组中的顺序进行拼接 — 排序在前面的词典内容早到可以早拼接，所有的读线程执行完毕后用户线程才会完成访问过程并将查询结果以文章内容形式反馈给用户。
依这一逻辑，同样的词典分组，如果用户将简单词典放在分组最前面的位置，内容多且结构复杂的词典和网络、应用程序型词典尽可能的放在分组后面，是可以提升查询效率的。
我个人主用Windows，没有明显感觉，可能我的词典比较少比较简单吧。
受馈信息来自使用 mac 的学友，我想或应是平台差异 — 在同样的实现下，Linux或Unix平台性能上应该是有明显的优势的，优化带来的效果应该也会比较明显吧。