当生成文本格式或长度较为复杂，可能导致程序假死或格式错乱

[qinweima]

env

obsidian: V1.8.9
platform: Windows 11 pro 24H2 26100.3476
tars: V2.1.0
API: 智谱 glm-4-plus
configuration: 启用网络搜索

现象描述：

1. 当生成文本内容较长，文本打印于obsidian编辑器中的速度会下降，严重时速度指数型下降甚至导致编辑器假死无法使用。
2. 当生成文本内容较长格式较为复杂，文本输入位置可能会错乱，导致格式出错。

现象1描述及复现条件：
概率极高，存在于生成文本较长情况下（无法验证是否与模型/生成内容的格式复杂程度/本地插件相关）。
复现示例：#User : 给我一个炫酷的markdown示例 或 #User : 给我一个复杂的mermaid示例

现象2描述及复现条件：
当生成文本格式较为复杂时，概率性输入指针位置偏移、文本格式错乱、内容错乱。
复现示例：同上

另外

非常感谢tars插件开发者，它真的非常简洁好用，如果有需要日志、或者环境相关问题请告诉我。

[qinweima]

在obsidian沙箱中测试，似乎这个现象与Blue-topaz这个主题存在联系

[ae86jack]

谢谢，我这边复现这个bug了，我这两天发个版本

[ae86jack]

刚刚发版的2.2.0，修复在生成内容过程中，遇到格式复杂，特殊符号的情况下，光标定位不准确，导致输出混乱的问题
麻烦你更新后试试，有没有解决你的问题

[ae86jack]

刚发版了2.3.0，提高内容生成的响应速度和渲染性能。麻烦看看性能有没有改进

[lnabc03]

刚发版了2.3.0，提高内容生成的响应速度和渲染性能。麻烦看看性能有没有改进

确实感受到了性能提升！比上个版本提速了约30%。
测试了deepseek-chat模型，输出一个1000字左右的回答，从开始到结束输出所用时间刚好60s。
500字以后卡顿仍然明显，但每次卡住的时间减少了，提升空间尚在😊

测试设备配置：
CPU: Intel(R) Core(TM) Ultra 9 285H (16) @ 5.40 GHz
GPU 1: Intel(R) Arc(TM) 140T GPU (16GB) (128.00 MiB) [Integrated]
Memory: 14.76 GiB / 31.50 GiB (47%)
Swap: 180.20 MiB / 2.00 GiB (9%)

[ae86jack]

你的obsidian 开启硬件加速吗？我也有台dell的轻薄本，性能比你的更差，但是1000字回答都没有卡顿。

[ae86jack]

测试性能时候，试下用默认主题，排除第三方主题的干扰。

[ae86jack]

这里讨论的性能问题是插件输出文字的速度，obsidian的渲染速度，赶不上API输出速度，导致的体验问题。如果API本身输出速度慢，这不属于插件问题。测试的时候，尽量是用最快的api响应，比如1分钟8000字，api调用结束后，插件是否还在输出，或者其他渲染问题。

[lnabc03]

测试性能时候，试下用默认主题，排除第三方主题的干扰。

感谢您的指出！硬件加速一直开着，我又用默认主题测试了一下，长文本输出完全没有卡顿。

目前基本可以确定obsidian的渲染速度赶不上API输出速度导致的卡顿问题主要来自blue topaz等第三方主题（但由于日常使用习惯，主题又不得不用），希望后续可以针对优化一下。

[qinweima]

刚刚发版的2.2.0，修复在生成内容过程中，遇到格式复杂，特殊符号的情况下，光标定位不准确，导致输出混乱的问题 麻烦你更新后试试，有没有解决你的问题

感谢！神速解决。

刚发版了2.3.0，提高内容生成的响应速度和渲染性能。麻烦看看性能有没有改进

在有主题等css的时候，长文本的表现还是不太尽如人意。猜测（纯外行）是否因为单个字符的更新均会导致重新计算渲染？如果是的话能否提供一个选项或是缓冲机制？类似拷贝方式，将缓冲中大段数据（而不是单个字符逐字输入）进行写入（=。=）！？

obsidian渲染机制完全不懂，纯猜测，见笑。

[ae86jack]

obsidian 是没有开源的，它是基于开源的markdown渲染库进行二次开发。文字更新，需要重新计算，判断是刚刚更新的是不是标题，是不是代码块，是不是callout（callout是obsidian自己定义的），如果是的话，需要把这些特殊语法正确渲染出来。
API的吐出速度是没问题的，主流的ai app 用开源的markdown代码都可以流畅渲染。
可能存在的问题是：

1. obsidian自己加了callout语法，并且支持实时编辑，这些代码没有开源，没有技术大佬过目，性能没有做到极致
2. 第三方的css 开发者很可能不懂 性能方面问题，如果css里面涉及很多计算，那么性能很慢。人手敲字是很慢的，对比AI输出。如果要用第三方css，建议用开源比较流行的，有资深技术大佬参与的

[qinweima]

感谢解惑，我马上会关闭本issue。
那目前我的选择只有两个了，从工作流分离tars，到另一个仓库。或是在某些文件禁用css，但我尚未找到有效的批量禁用主题内样式或者单个文件内禁用主题css文件的方法，大佬和其它朋友能否给出相关的建议？

[ae86jack]

还有一种解决方案，当你觉得要输出长文本的时候，把编辑模式从“实时阅览”改为“源码模式”，这样obsidian不用去渲染，等输出完成后，再把编辑模式改回“实时阅览”。