Obsidian重、启动慢时的
分割步骤
本页面由日语原文机器翻译而成。 阅读日语原文
首先保管原来的保管库，在复制的保管库中分离插件和设置。 刊登在作者的小验证保管库中测量的9次结果，作为在相同条件下进行比较的例子。
在更改设置之前，保管原来的保管库
确保笔记、附件、设置的备份，用验证用副本而不是原来的保管库进行测试。 将社区插件统一禁用，比较显示相同笔记的时间，如果有差异，逐一返回确认。
.obsidian 也作为设定包含。 请确认副本存在，可以读取已知的笔记后，请更改设置。 不是删除原来的笔记和插件文件的步骤。从这里开始的分割是面向读者的提案。 不是诊断读者终端原因的结果。 后半部分的实测只处理作者准备的1笔记本的固定条件。
- 保管原来的笔记本・附加・设置
- 分症状启动・正文显示・编辑中
- 用复制比较相同的笔记・相同的标准
- 一个一个恢复记录版本和变更
将“重”分开，用验证用副本确认
- 记下哪个阶段比较慢。 在启动
应用程序之前，在打开保管库看到正文之前，搜索、链接、编辑的过程中，都是不同的症状。 记录OS、Obsidian的版本、保管库的大致规模、之前更改的设置和有效的插件。 - 确认备份，将验证的副本分开。
应用程序关闭并制作副本，原件保持保存状态。 确认放置位置，以免将验证用副本与自动同步对象混淆，在两个同时打开的情况下不要更改设置。 不需要使用陌生人的保管库或未确认的插件。 - 通过复制禁用社区插件进行比较。
在记录有效的列表和设置后，从社区插件的设置中使用无效化和Restricted mode（限制模式），在重启后看到相同的已知笔记之前进行比较。 菜单的显示请用版本、语言确认。 插件停止时，该插件所承担的功能将无法使用。 - 如果看到差异，一个一个地恢复有效。
保持相同的副本、笔记、核心功能、测量标准，记录插件的名称、版本、激活的顺序。 多次测量相同的条件，避免仅根据第一次的时间或一次的快速值得出结论。 - 如果看不到差异，就分开比较保管库和环境。
在自己准备的小笔记本的单独保管库中，确认同一阶段是否慢。 同时记录运行的应用程序和OS负荷、同步、存储状态等。 如果在这里一次性更改设置和文件，就无法知道与哪个更改有关。
备份的制作、切换到限制模式、读者的插件的回放、同步・存储的诊断，不是这个9次的测量中演示的操作。 实测使用事先准备好的激活列表，没有进行启动中的操作和笔记改写。
在固定的小保管库中，0・1・2个各3次测量
使用相同的Linux环境和作者制作笔记，比较了实际导入的社区插件是0个、只有Templater的1个、Templater+QuickAdd的2个的条件。 本文显示的中位数分别约为0.92秒・0.95秒・1.02秒。
| 执行时读取的插件 | 测量次数 | 测量用连接的准备 CDP ready | 已知的正文显示 GUI text ready |
|---|---|---|---|
| 0个：2种都无效 | 3次 | 中值 324 ms 范围 313–356 ms | 中值 917 ms 范围 892–949 ms |
| 1个：Templater 2.25.1 | 3次 | 中值 325 ms 范围 315–339 ms | 中值 948 ms 范围 926–973 ms |
| 2个：Templater 2.25.1 + QuickAdd 2.29.0 | 3次 | 中值 329 ms 范围 325–332 ms | 中值 1017 ms 范围 1016–1105 ms |
0个也有2种的分发文件。 更改的是社区插件的激活一览表。 不仅计算已安装的manifest，还读取了运行时的有效列表和实际插件实例的ID・版本，确认了0・1・2个。 核心功能在所有条件下都是相同的5种。
这个顺序的中值，不能作为插件数的因果关系和一般的“越多越慢”定律。 插件的种类随着数量的变化而变化，每个3次很少，共享CPU和缓存也不固定。 请不要将这种差异直接应用到读者的大型保管库和终端上。
测量了启动的“到什么程度”
连接的准备和正文的显示分开
用单调增加的时钟，测量了从启动Obsidian进程之前开始的经过时间。 显示环境的准备在开始前就已经做好了。 CDP ready是测量用的连接点响应，获得连接点信息的时间点。 仅凭这一点，不能说屏幕上显示了笔记。
GUI text ready是使用该连接确认真实画面，起動確認.md的标题“起動確認”和已知的确认标记显示的时间点。 包括从启动到连接、读取处理。 与最初的绘制、所有插件的初始化完成、可以编辑的时间点是不同的指标。 读取件数的状态确认，在本文显示的观测后另行记录。
使用相同的输入和顺序
- 官方Obsidian 1.13.7。 在实际的General画面中确认了应用程序和installer的版本。
- Templater 2.25.1、QuickAdd 2.29.0的相同官方分发文件复制到全部条件。 这次没有新的获取、依赖的安装。
- 输入是作者直接准备的148字节的Markdown 1件。 使用相同的保管库设置、核心功能5种、两个插件的分发文件，在启动前核对了激活列表以外的保管库文件。 启动后正文的bytes/hash也没有改变。
- 核心功能是file-explorer、backlink、outline、properties、bookmarks。 没有执行Templer的启动template和QuickAdd的choice・macro・AI设置等。
- 事先确定0・1・2个3条件和各3次，按照
0,1,2 / 1,2,0 / 2,0,1的顺序进行测量。 预定的9次全部刊登，没有只筛选快速值和删除偏离值。 - 测量中点击GUI，打开・写笔记API，不执行插件命令，通过读取确认状态。 每次都保存了实画面，只让测量时使用的应用程序正常结束。
缓存、负载、配置文件的极限
首先在未测量的准备用配置文件中，进行实际的信任确认和General的版本确认，将准备好的设置复制到每次。 每次制作新的配置文件、缓存用目录，OS的页面、磁盘缓存通过准备和重复来升温。 没有重启或清除OS缓存，不是物理冷启动或第一次未使用设置。
关于每次的整个全局配置文件，没有记录启动前的完整hash一览表。 虽然保留了共同的准备原始设置和复制方法，各保管库的启动前文件核对，但并不主张所有配置文件的所有bytes是相同的。
在共享环境中，CPU使用率的观测值约为35–44%，其他应用程序也在运行。 可见的逻辑CPU是5，CPU分配相当于4 CPU，内存上限是16 GiB。 CPU的观测区间包括测量、状态获取、图像保存，不是个别插件的CPU使用率。 准备前还确认了其他构建工作，但并不是在所有9次中运行相同的构建的记录。
关于测量前的停止和记录的更正
在未测量的准备阶段，检查正常结束的应用程序的连接目的地是否被释放的检查，将TCP的TIME_WAIT与待接中的连接混淆而停止。 保管失败记录，确认无待接、拒绝连接，更正检查后，测量了预定未实施的9次。 准备阶段的时间没有放在测量样本中。
在原图像的一览确认中，将准备用的信任确认画面计算掉的11件的预期值更正为12件。 图像、GUI、时间不重新生成，保留现有的CSV等bytes，更正记录的件数。
确认原来的CSV、笔记、实画面
CSV是包含未四舍五入的9次的时间、执行时的读取件数和版本、共享负载、结束结果的原始文件。 除了表中的整数以外，可以确认原来的值。 Markdown是作者事先直接准备的输入，不是通过应用程序保存正文的成果。
# 起動確認
著者作成の固定ノートです。プラグインの起動比較にだけ使います。
表示確認印 C21-STARTUP-20260930
刊登的4图像和CSV・Markdown是冻结的原件和bytes・SHA256一致的副本。 原来的验证receipt包含23项目的确认和82文件的bytes/hash，包含receipt本身的核对范围是83件。 在这次9次中，没有测量Windows・macOS・iOS、大型实用保管库、同步、SimpleMemo的速度、生产力、流入效果。 测量条件和原件的核对记录。