Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Optimize document moving and renaming performance #10560

Closed
3 tasks done
UFDXD opened this issue Mar 9, 2024 · 31 comments
Closed
3 tasks done

Optimize document moving and renaming performance #10560

UFDXD opened this issue Mar 9, 2024 · 31 comments
Assignees
@88250
Labels
Enhancement
Milestone
3.0.5

Comments

@UFDXD
Copy link

UFDXD commented Mar 9, 2024 •
edited by 88250
Loading

在现在文档树文件移动文件是否过于慢了

Is there an existing issue for this?

  • I have searched the existing issues

Can the issue be reproduced with the default theme (daylight/midnight)?

  • I was able to reproduce the issue with the default theme

Could the issue be due to extensions?

  • I've ruled out the possibility that the extension is causing the problem.

Describe the problem

虽然不是最新版，但也没离几个版本。

就也没多少个文件，就文档树文件普通移动，但是现在就是这么多一个包含子文件的文件移动到其他文件下，甚至同级移动改一个顺序就要花很多时间，已经感觉不能忍受了。反馈看看是不是BUG问题
image_74

Expected result

文件普通移动操作不应该花费这么长时间。

Screenshot or screen recording presentation

1

Version environment

- Version: v2.12.8
- Operating System: 
- Browser (if used):

Log file

部分日志.txt

More information

No response
@UFDXD
Copy link
Author

UFDXD commented Mar 9, 2024 •
edited
Loading

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

@88250 88250 self-assigned this Mar 10, 2024
@88250
Copy link
Member

88250 commented Mar 10, 2024

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

@UFDXD
Copy link
Author

UFDXD commented Mar 10, 2024 •
edited
Loading

@88250

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

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

@88250
Copy link
Member

88250 commented Mar 10, 2024 •
edited
Loading

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

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

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

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

@88250 88250 closed this as completed Mar 10, 2024
@88250 88250 mentioned this issue Mar 15, 2024
Closed
@88250
Copy link
Member

88250 commented Mar 15, 2024

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

@UFDXD
Copy link
Author

UFDXD commented Mar 16, 2024

@88250 好的

@UFDXD
Copy link
Author

UFDXD commented Mar 18, 2024 •
edited
Loading

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

@UFDXD
Copy link
Author

UFDXD commented Mar 18, 2024

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

@88250
Copy link
Member

88250 commented Mar 18, 2024

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

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]

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

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

@UFDXD
Copy link
Author

UFDXD commented Mar 18, 2024

@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]

@UFDXD
Copy link
Author

UFDXD commented Mar 18, 2024 •
edited
Loading

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

@UFDXD
Copy link
Author

UFDXD commented Mar 18, 2024

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

@TCOTC
Copy link
Contributor

TCOTC commented Mar 18, 2024

@UFDXD 只能说预先一次性设计好笔记本的层级和架构，整理一遍，之后尽可能少大批量移动文档

@UFDXD
Copy link
Author

UFDXD commented Mar 18, 2024 •
edited
Loading

@TCOTC 这问题是因为，我本来是传统的文档树用户，开始用思源根本不懂反链的是什么。后来也就是最近用上思源自带的标签。但是思源自带的标签很简单，无法支撑后期灵活的修改。然后逛社区发现有人用引用代替标签兼得反链后期素材整理文章输出。我这一用发现好用哇。然后就是用上了反链，走引用标签这条路了。所以问题就是出在这里，在用之前积累了大量文档树结构文档，这部分现在逐渐在分化整理，然后就发现了这个索引性能问题。

@TCOTC
Copy link
Contributor

TCOTC commented Mar 18, 2024

@UFDXD 我今天也在整理文档树，因为文档不多所以没什么感觉。看来以后也要注意了。

@TCOTC
Copy link
Contributor

TCOTC commented Mar 18, 2024

好吧，刚才移动了一个子文档稍微多点的，卡住10秒，确实太慢了

@UFDXD
Copy link
Author

UFDXD commented Mar 18, 2024 •
edited
Loading

😥

@TCOTC
Copy link
Contributor

TCOTC commented Mar 18, 2024

刚才移动了一个子文档比较多的（但不到50个），卡住40秒，更慢了

@UFDXD
Copy link
Author

UFDXD commented Mar 18, 2024

@TCOTC 所以说这是难以忍受的。而且这期间什么都不能做。来回修改父文件文档名也是的。

@88250
Copy link
Member

88250 commented Mar 19, 2024

目前性能瓶颈主要在修改块的 HPath 上

siyuan/kernel/sql/database.go

Line 1214 in 9576409

func batchUpdateHPath(tx *sql.Tx, boxID, rootID, newHPath string, context map[string]interface{}) (err error) {

各位有空可以帮忙想想办法。

@88250 88250 changed the title 在现在文档树文件移动文件是否过于慢了 Optimize document moving and renaming performance Mar 19, 2024
@88250 88250 reopened this Mar 19, 2024
@TCOTC
Copy link
Contributor

TCOTC commented Mar 19, 2024

整理文档树会时不时卡住几十秒真的是灾难，希望有办法优化🙏

另外问了一下 GPT-4 ，回复可能没什么卵用，但还是附在这里了：

针对您提供的代码和描述的性能瓶颈问题，我会给出一些建议来尝试提高性能。

1. 批量更新

首先，如果 batchUpdateHPath 函数被频繁调用，每次只更新少量记录，那么可以考虑将多个更新操作合并为批量更新，以减少数据库操作的次数。但是，基于您提供的代码片段，这里的更新操作已经是针对特定条件的批量更新，因此这个建议可能不适用。

2. 索引优化

确保 blocks 和 blocks_fts 以及 blocks_fts_case_insensitive 表上的 box 和 root_id 字段有适当的索引。缺乏索引会导致更新操作非常缓慢，尤其是在大数据量的情况下。

3. 减少不必要的更新

如果 hpath 的新值与旧值相同，那么不执行更新操作可以节省时间。这需要您在代码中添加逻辑来检查 hpath 是否真的发生了变化。

4. 并行处理

如果业务逻辑允许，并且您的数据库能够处理并发写入，您可以考虑将更新操作分散到多个事务中并行执行。但请注意，这可能会增加复杂性，并且需要确保数据一致性和事务隔离级别。

5. 减少事件总线的负载

eventbus.Publish 调用可能是一个隐藏的性能瓶颈，尤其是如果它执行了一些耗时的操作，或者等待某些资源（如网络I/O）。考虑异步发布事件或优化事件处理程序。

https://github.com/siyuan-note/siyuan/blob/95764092ecea75d0c6e7c8e59839d7bec9d5b2f0/kernel/sql/database.go#L1214C1-L1233C2

@88250
Copy link
Member

88250 commented Mar 19, 2024

@TCOTC 稍后我试试，多谢。

@88250
Copy link
Member

88250 commented Mar 19, 2024 •
edited
Loading

找到个优化方案可以大概提升 40% 的时间：

  • 减少 UPDATE ... WHERE 条件，从 box AND root_id 减少为 root_id，因为 id 跨笔记本也是唯一的
  • blocks 表 root_id 加索引

另外，还要考虑输入标题时待用户确认以后（焦点离开）再调用重命名 @Vanessa219

@88250 88250 added this to the 3.0.5 milestone Mar 19, 2024
88250 added a commit that referenced this issue Mar 19, 2024
@88250
⚡ Optimize document moving and renaming performance #10560
9bc6415
88250 added a commit that referenced this issue Mar 19, 2024
@88250
⚡ Optimize document moving and renaming performance #10560
de02e66
@TCOTC
Copy link
Contributor

TCOTC commented Mar 19, 2024

输入标题时待用户确认以后（焦点离开）再调用重命名

如果焦点没离开就关闭了思源，不知道会不会有问题

@88250
Copy link
Member

88250 commented Mar 19, 2024 via email

@88250
Copy link
Member

88250 commented Mar 20, 2024

和 V 讨论了下，焦点离开提交修改比较危险，容易漏提交数据，所以这部分交互暂时还是不动了，这个 issue 仅优化后端性能。

@88250 88250 closed this as completed Mar 20, 2024
@UFDXD
Copy link
Author

UFDXD commented Mar 20, 2024 •
edited
Loading

@88250 还是这个文档，接上一次这次将其还原移动到原来的父级，也就是作为子文件夹。花费时间感觉还是不容乐观。（移动之前尝试同级移动了一次，是瞬间移动，好的这个好评）

日志.txt

@88250
Copy link
Member

88250 commented Mar 20, 2024 via email

@88250
Copy link
Member

88250 commented Mar 21, 2024

@UFDXD 对了，要重建索引以后再测试，应该有近一半的性能提升。

@UFDXD
Copy link
Author

UFDXD commented Mar 21, 2024 •
edited
Loading

@88250 重建索引后连续测试了三次（其实四次）结果就是，还是太坐牢了。这里贴出测试日志（日志里我写了一些方便查看开始结束的备注）
日志.txt

@88250
Copy link
Member

88250 commented Mar 21, 2024 •
edited
Loading

收到，这部分后面再看看是否还有其他方案，其他开发者看见也可以帮我们想想，多谢！

@88250 88250 mentioned this issue Mar 28, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@88250 88250

Labels
Enhancement
Projects
None yet
Milestone
3.0.5
Development

No branches or pull requests
4 participants
@88250 @Vanessa219 @TCOTC @UFDXD