另外备注，我最后移动操作移动的文件就是截图中的这个文件，就是同级移动改个顺序（文档树拖动，指示条卡住，等了好久完成了指示条消失，文档转移顺序成功），就花费了漫长的时间。

是移动的父文档还是多选子文档移动？

@88250

都有吧，子文档也可以是有子文档的吧。这个使用场景上无法小心的区分开来，不然的放着移动父文档不用，要展开子文档要一个一个多选有些离谱（存在限制展开多少子文档选项，如果子文档很多超过200，我限制显示100，那么多的就无法手动选择完全，即使花时间一个一个手点和还有一个shift+下批量快捷选中都是不方便的和无法全部选中的）。

还有反馈一个类似的性能问题，如果这个文档有很多子文档子文档正常有自己的子文档，那么像上面截图的体量文件的话，改变文件名就会缓慢。现象就是，文档打开的文档名是已经改好了，但是文档树的文档名没有变（有时候看文档树的没变会重新改一次，然后我怀疑后台会也会加入队列任务重复再跑一次改动，反正我第一次遇见这个情况文档中改，文档树中改，导致后台改名跑了好久，不得不挂机看视频去了），下栏可以看到后台在以一个小批量一次的比较缓慢的速度改变着什么。

目前的逻辑是移动文档超过 64 个的话（不算子文档，只算移动的这一层）会弹进度遮罩 #9356

目前的实现代码暂时找不到优化空间了，主要是移动的时候需要加载解析文档和在文件系统上移动文件，如果子文档很多的话确实会比较慢。

移动和重命名逻辑上是一样的，都需要修改 hpath，所以重命名也会比较慢。

我关闭了，后续如果有优化方案的话再打开，感谢反馈。

下个版本会优化索引性能，麻烦帮忙对比测试 #10624

@88250 好的

@88250 还是这个文件（包含这么多子文件），尝试移动到它的父级。时间感官上花了二十几分钟（不确定具体时间，因为期间看直播去了，具体时间我贴出了日志），是有速度提升吧，但还是比较慢。
部分日志.txt

发现这个用户和我差不多的的问题，不过还没有被回复，这里贴一下关联一下。https://ld246.com/article/1710474212925

看一下启动后打印的数据量日志，就是这一部分：

I 2024/03/18 20:00:00 conf.go:807: database size [1.4 GB], tree/block count [10077/509386]
I 2024/03/18 20:00:00 working.go:192: kernel booted
I 2024/03/18 20:00:01 box.go:76: auto stat [trees=10077, blocks=509386, dataSize=1.3 GB, assetsSize=974 MB]

移动文档后需要批量重建索引，这样才能保证搜索路径和引用路径的正确性，以目前的结构来看，优化空间很小了。

估计只能考虑将不常用的文档存档以降低总的数据索引量来顶顶了。

@88250 I

2024/03/18 23:19:17 blocktree.go:495: read block tree [146 MB] to [H:\My-Instrument\Software\思源笔记\思源工作空间\temp\blocktree], elapsed [0.49s]
I 2024/03/18 23:19:17 conf.go:807: database size [2.0 GB], tree/block count [3830/370074]
I 2024/03/18 23:19:17 working.go:192: kernel booted
I 2024/03/18 23:19:17 serve.go:128: reverse proxy server [127.0.0.1:6806] is booting
I 2024/03/18 23:19:18 box.go:76: auto stat [trees=3830, blocks=370074, dataSize=3.6 GB, assetsSize=3.3 GB]
I 2024/03/18 23:19:18 disk.go:33: disk usage [total=90 GB, used=33 GB, free=56 GB]

@88250 对我来说不可能封存的，因为我是引用当标签的呀，就是通过标签反链（这是思源的优势而且实际体验下来只要标签打的好非常好用，现在我大到文档小到碎片信息一句话打上标签就丢文档里面了），日后在笔记里找素材的时候就是能看到丢在那个角落的文档。封存了就没记笔记的搞这个体系的意义了。而且现在移动文档速度感人，不敢大批量移动。总之我觉得如果现阶段找不到优化办法的话，后面每个深度思源笔记用户都会遇到这个问题（除非完全砍了文档树，但以现在用户体量来说不现实，而且文档树有文档树的优势）相信会有越来越多用户反映（其实应该有不少用用户发现了，但是就像我对思源有极大的忍耐性，因为思源是敏捷开发BUG多是常是但都在两到三个小版本内就解决了，所以都看看是否有其他人提，都有观望性，不到难受到极点自己是不会说的）

@88250 总之如果实在没有优化办法的话，就只能将就这用了。