这问题我感觉自己不是特别适合回答, 希望有更懂这些知识的小伙伴帮忙
首先仓库里大量笔记是没啥事的, 我自己也有笔记数 3000 到 6000 不等的几个仓库
但对于笔记都堆放在同目录的场景:
右键里的“在文件列表中显示当前文件”定位文件
但如果该文件是在那个2万多个文件的文件夹里的话，就会卡很久，甚至卡死
我弄了个 Zettelkasten-Method/10000-markdown-files: Useful for stress testing note-taking tools. 项目试了试, 下载完后同级目录有 10000 个笔记, 没敢用旧电脑打开
然后我换了个好点的电脑, 10000 个笔记还是很卡,
最后我只留了同级别 2000 个笔记做的测试
按照楼主的操作, 把 2000 笔记目录做成 Ob 库的子目录 (一上来在侧栏文件列表不默认展开),
然后 README 页面随机造几个双链, 点开笔记后立刻点 “在文件列表中显示当前文件”
同时 console 里录制性能分析报告, 如下
解释:
我总共录制了 38秒, 其中有两次在笔记的页签上点击 “在文件列表中显示当前文件”
这两次点击都造成了性能瓶颈, 见时间进度条那俩红圈
每次鼠标互动耗时约 350毫秒, 这已经是用户可以感知的耗时了
那么性能瓶颈的本颈在哪?
我没看懂,
根据它分析报告, 是 “重新计算样式” 和 “布局” 这两项触发了 “强制自动重排”,
见截图
疑似这任务需要操作一万多节点的 removeClasses 但这是否真的开销很大, 我就不懂了
哦, 刚找到一篇介绍写的很细: “重排步骤包括 Recalculate Style、Layout、Update Layer Tree 等渲染类型时间” … “由于计算布局需要大量时间，重排的开销远大于重绘，在达到相同效果的情况下，我们需要尽量避免重排” ref
所以回到楼主问题
如果该文件是在那个2万多个文件的文件夹里的话，就会卡很久，甚至卡死
我这个是无插件无主题的新仓库, 尚且如此,
楼主的主力仓库若是同级目录两万文件, 那还真得小心点使用
除了分文件夹放，还有其它好方法吗?
暂时没想到特别靠谱的
楼主明显已经试过许多了
在当前没好方案的情况下, 也许考虑少用这个 “在文件列表中显示当前文件” 以及类似的高耗时操作
假设需求是大量读+少量改, 这时 “读” 一般没啥事, “改” 若是低频需求那费事也就忍了
假设需求确实就是频繁的修改带反链笔记, 必须依赖 Ob 全库自动重命名笔记的, 确实没想到好法子
这个是算ob底层的bug呢? 还是有其它解决方法呢?
个人理解 “同级目录放太多文件” 不是 “普遍使用情形”, 于是软件没特意做优化
另举网页的例子, 就是上文那个一万笔记项目, 可看到 github 网页预览也是直接砍到前一千文件 ref 还给提示 “Sorry, we had to truncate this directory to 1,000 files. 9,000 entries were omitted from the list. Latest commit info may be omitted.”
另举文件系统里的例子, 像 git 存 object 时也是把 object hash 前两位字符拎出来, 单独建层子目录存放, 原因之一可能是为规避同目录下文件太多