因为都是同一性质的文件，文件之间又有联系，所以都放在同一个文件夹里，分文件夹放反而会破坏文件之间的联系，而且会增加不必要的工作量
电脑资源管理器里能秒开，但从ob文件列表里打开该文件夹的话得要好几分钟，因为在ob之外修改文件的话可能会破坏链接, 所以有时不得不在ob里打开该文件夹来操作
有时也会用右键里的“在文件列表中显示当前文件”定位文件，但如果该文件是在那个2万多个文件的文件夹里的话，就会卡很久，甚至卡死. 除了分文件夹放，还有其它好方法吗?
这个是算ob底层的bug呢? 还是有其它解决方法呢?
这问题我感觉自己不是特别适合回答, 希望有更懂这些知识的小伙伴帮忙
首先仓库里大量笔记是没啥事的, 我自己也有笔记数 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 前两位字符拎出来, 单独建层子目录存放, 原因之一可能是为规避同目录下文件太多
1 个赞
应该没解决办法，ob没做优化
非常感谢这么专业的分析 
是的, 几乎不敢碰那个文件夹
另外, 你用于测试的文件可能里面还含有内容, 我那2万多个文件几乎是空文件, 最多写个yaml区, 主要是用于收集反链用的
文件数还会持续增加, 目前是先用右键中的"在系统资源管理器中显示"当前文件, 在电脑资源管理器中查看, 遇到可能会影响双链同步问题的修改时, 再在ob里搜索相关文件, 直接在标签页里打开相应文件再做修改
2 个赞
一直关注笔记性能问题。看到这个 10k-md 库，就下载试了一下。顺便反馈在这里。
-
Obsidian 打开，很流畅，包括楼主遇到的文件列表中显示1万条文件，也很顺畅。查询 [[the]] 也速度很快。ps 中文我压力测试就查询 [[的]]
-
Logseq 打开，可能要 20分钟以上，打开后日常操作还可以，但第2次打开就没耐心等待了，直接退出了。
楼主分析和做法很理性，没办法解决，只能避开。无力补充。
但「多数是空文件、为了反链查询」这一背景，还是怀念 Logseq 思路：
- 创建[[尚未建立的笔记]]，甚至双击打开时，并不会创建对应的 md 文件；
- 直至写了正文保存时，才建立 md 文件。
很多时候，懒是正道。
ps. 所以，推荐所有 Obsidian 安装插件超过5款，希望提升速度的用户，安装刚发布的插件： Lazy Plugin Loader 。通过插件延后加载，提升启动速度。
ps. 测试全程录屏： 10k MD 测试 Obsidian Logseq -20240911
链接：芦笋录屏官网 - 新一代录屏软件
1 个赞
这个延迟启动插件和plugin group 插件相比，哪个好？
后者我试过分组不同时间延后启动，但是似乎有时候第一波启动会静默失败。