Reduce database table view editing latency

[frostime]

优化 Database 的编辑延迟

In what scenarios do you need this feature?

目前数据库编辑内容后到内容生效之间有一个明显的延迟

Describe the optimal solution

是否可以优化一下，让编辑看上去更加跟手？比如不要等到发送给后端之后再更新前端的显示，让编辑的过程看上去更加流畅一些。

Describe the candidate solution

No response

Other information

No response

[zxhd863943427]

字段名没有研究过。但是我测试过，将字段值的更新改为使用setAttributeViewBlockAttr，也就是块属性面板中设置数据库属性的api，性能会有一个极大的提高，这是什么原因引起的？

[88250]

@zxhd863943427 主要原因是要等后端 transaction 返回，后端是间隔轮询执行的。楼主提议是做完全异步，这是优化方向。

[88250]

9338 改进了下事务队列机制，稍微快了那么一丢丢。

[liao-zh]

+1， 最近弄了个100多行的表，编辑有时都卡死了，过滤、排序也有点慢。（v2.10.15） 期待流畅丝滑的体验哦

[88250]

@littlecoby 编辑卡死的问题可以稳定重现吗？

[liao-zh]

@littlecoby 编辑卡死的问题可以稳定重现吗？

不大确定什么时候会卡死。行数多了编辑的时候都卡，有时卡着卡着就界面都动不了了。

现在点击添加行后是先随便打些字，然后再点”更多“来建立块引吗，这样编辑的体验有一点割裂感。希望能边打字边出现块引列表，如果不需建立块引可以按esc退出之类的。

另一个问题是，添加行的按钮在最下方，新增的行会出现在最上方，如果行数比较多，窗口里就看不到新行了。建议点击最下方的“添加”时，新行暂时出现在最下方；有个issue似乎要在顶部也加一个”添加“按钮，点击时新行暂时出现在顶部。

[zxhd863943427]

现在点击添加行后是先随便打些字，然后再点”更多“来建立块引吗，这样编辑的体验有一点割裂感。希望能边打字边出现块引列表，如果不需建立块引可以按esc退出之类的。

我不能同意这个，部分人就是当成加强版表格来用的。

[88250]

另一个问题是，添加行的按钮在最下方，新增的行会出现在最上方，如果行数比较多，窗口里就看不到新行了。建议点击最下方的“添加”时，新行暂时出现在最下方；有个issue似乎要在顶部也加一个”添加“按钮，点击时新行暂时出现在顶部。

这应该是因为启用了排序。

[liao-zh]

现在点击添加行后是先随便打些字，然后再点”更多“来建立块引吗，这样编辑的体验有一点割裂感。希望能边打字边出现块引列表，如果不需建立块引可以按esc退出之类的。

我不能同意这个，部分人就是当成加强版表格来用的。

数据库刚公测的时候好像只能块引，现在变成这样，估计是这个原因。 所以我的提议兼顾了两种用法。 或者编辑时块引列表第一个选项设成”不建立块引“，这样即使习惯按回车也没事。

[liao-zh]

另一个问题是，添加行的按钮在最下方，新增的行会出现在最上方，如果行数比较多，窗口里就看不到新行了。建议点击最下方的“添加”时，新行暂时出现在最下方；有个issue似乎要在顶部也加一个”添加“按钮，点击时新行暂时出现在顶部。

这应该是因为启用了排序。

确实设了修改时间降序。 但如果每次”添加“前都取消排序也不方便。 所以建议是”暂时“放在底部或顶部，毕竟”添加“后第一列是默认处于编辑状态的，等退出编辑了再参与排序。

现在数据库使用上最主要的问题还是卡顿。

[88250]

嗯，排序添加暂时不动了。卡顿是前面说的卡死还是这个 issue 反馈的编辑延迟？

[liao-zh]

嗯，排序添加暂时不动了。卡顿是前面说的卡死还是这个 issue 反馈的编辑延迟？

主要是编辑延迟吧，100多行的表里可以稳定复现，编辑、排序、筛选都有可见的延迟。 我猜如果延迟的问题解决了，就不会卡死了。

[88250]

编辑延迟暂时是解决不了了，但是排序和筛选不应该有太大延迟，麻烦录屏我看下延迟时间是否正常。

[zxhd863943427]

这是我更换接口后的速度：

https://github.com/siyuan-note/siyuan/assets/74853597/17bcda5e-e6c8-4ec7-af3e-8c46e1fb029e

我觉得编辑延迟的提升还是很明显的。

具体代码在 https://github.com/zxhd863943427/siyuan/tree/dymicUpdateCell

[liao-zh]

这是一个123行数据表的例子。 刷新后加载了3s，排序用了8s，过滤面板弹出用了3s，过滤用了4s。

https://github.com/siyuan-note/siyuan/assets/27865589/12e46879-e891-4ed0-820a-4602b3a7c4d7

https://github.com/siyuan-note/siyuan/assets/27865589/242dc16a-527f-4a6e-88b5-56c4f3ea70bc

https://github.com/siyuan-note/siyuan/assets/27865589/19809fce-4d32-445e-b61d-9edcbd7f6661

[88250]

@littlecoby 大概定位到这个问题了，是更新时间列影响的，我们单独开一个 issue https://github.com/siyuan-note/siyuan/issues/9719

[liao-zh]

@littlecoby 大概定位到这个问题了，是更新时间列影响的，我们单独开一个 issue #9719

赞👍

[liao-zh]

@littlecoby 大概定位到这个问题了，是更新时间列影响的，我们单独开一个 issue #9719

赞👍

[liao-zh]

@littlecoby 大概定位到这个问题了，是更新时间列影响的，我们单独开一个 issue #9719

另外，过滤和排序面板要不要加一个”确定“按钮？

在第二层级的时间这里，选完之后有些不知道该点哪里，加个按钮比较清晰。

至于第一层级的面板，加了按钮可以等所有条件都选好之后一起过滤，不加按钮可以实时过滤，各有优劣吧。不过如果第二层级的加了按钮，在第一层级也加就有一致性。

[liao-zh]

现在点击添加行后是先随便打些字，然后再点”更多“来建立块引吗，这样编辑的体验有一点割裂感。希望能边打字边出现块引列表，如果不需建立块引可以按esc退出之类的。

我不能同意这个，部分人就是当成加强版表格来用的。

数据库刚公测的时候好像只能块引，现在变成这样，估计是这个原因。 所以我的提议兼顾了两种用法。 或者编辑时块引列表第一个选项设成”不建立块引“，这样即使习惯按回车也没事。

或者在设置中加个开关，选择默认是否弹出块引列表

[Vanessa219]

另外，过滤和排序面板要不要加一个”确定“按钮？ 在第二层级的时间这里，选完之后有些不知道该点哪里，加个按钮比较清晰。

选完以后直接 enter 或者点击空白，或者点击第一层的菜单的标题

[liao-zh]

另外，过滤和排序面板要不要加一个”确定“按钮？ 在第二层级的时间这里，选完之后有些不知道该点哪里，加个按钮比较清晰。

选完以后直接 enter 或者点击空白，或者点击第一层的菜单的标题

感觉没有”确定/应用“按钮方便，特别是过滤的二级菜单那里（如选择时间范围）。 从光标的动线来看，选完第一行和第二行的条件之后，自然会继续往下挪，但下一行却是”删除“。如果点击面板之外的空白，会连一级菜单也退出；如果要回到一级菜单，得把光标往上挪回一级菜单。 如果在”删除“之上加一个”确定“或者”应用“按钮，动线是从上往下挪，会顺畅一些。 enter键小小的不便之处是，之前都是鼠标点击，需要突然换到键盘。

另外按钮名称可能有些模糊。比如”新建“给我的第一感觉是可以创建不同的过滤条件A or B，我想用A的时候点A，想用B的时候点B，用的时候才知道是A and B的关系。 ”新建“可以改成”添加条件“。 ”删除“可以改成”清空条件“。 ”过滤“在比如WPS里是叫”筛选“，听起来更符合平时的表达。

[Vanessa219]

那就做如下改进：

1. 有二级菜单时，空白一级菜单不消失
2. 文案修改

[liao-zh]

那就做如下改进：

1. 有二级菜单时，空白一级菜单不消失
2. 文案修改

okok，先用用看看

[Vanessa219]

4bd45961fa0a5bd61159fed41fb0b34387a3477c

[zxhd863943427]

transactions的耗时是另一个api的10倍左右，从性能分析中，可以发现其实这个才是性能瓶颈。

可以做一个很简单的测试，性能测试里把CPU降低四倍速度。会发现思源的database没有明显变慢。

然后把网速改为低速3g，database的卡顿立刻就变得很明显。

能否考虑在保留撤销栈的情况下使用后一个api？在我个人测试的分支上进行了尝试，效果的提升是很明显的。

[88250]

保留撤销栈的情况

不好搞。

另外，目前已经优化差不多了，编辑好像不卡了。