Android: 1,318ms of plugin startup time is unattributed ("Other"), and 2.8s is spent before any plugin loads

Bug reports
1

### Steps to reproduce

  1. On Android, with a 230-file vault and 9 community plugins enabled, force-stop Obsidian (or reboot) so the next launch is a cold start.
  2. Launch Obsidian and wait for it to settle.
  3. Open the start-up time breakdown and copy it.
  4. Repeat steps 1–3 at least three times.

Did you follow the troubleshooting guide? [Y]

Expected result

  • Every millisecond in the breakdown is attributable to a named component, so a slow launch can be traced either to a specific plugin or to Obsidian itself.
  • Deferring a tab removes its cost from startup rather than merely moving it outside the measured window.
  • On a small vault, the pre-plugin portion of startup should not dominate the launch.

Actual result

  • Total startup: **8,892ms**.
  • **1,318ms (14.8% of the whole launch, 21.7% of all community-plugin time) is reported only as “Other”**, with no plugin named. It is larger than the load time of 7 of the 9 enabled plugins, and larger than every plugin except the top two. There is no way to tell whether this time belongs to a plugin, to Obsidian’s plugin loader, or to deferred work — so the breakdown cannot answer the only question it exists to answer.
  • **2,804ms (31.5% of the launch) is spent before any community plugin loads**: Initialization 1,270ms, Vault 616ms, Workspace 569ms, Core plugins 349ms.
  • Vault → **Reading files costs 562ms for 230 files (~2.44ms/file)**. For comparison, other publicly posted 1.13.8 (367) breakdowns from a Pixel 9 show 1,002–1,082ms for 3,632 files (~0.28ms/file) — roughly 8–9× faster per file.
  • Boot → **Script evaluation is 804ms**, vs. 254–287ms on those same Pixel 9 reports — about 3× slower on the identical app build.
  • Workspace → Layout → **Load layout is 363ms even though 8 of 9 tabs are deferred**. The deferred tabs are still built shortly after the timer stops, so the cost is not removed, only hidden from the measurement.
  • By contrast, **Core plugins (349ms) is in line with the Pixel 9 baseline (332–354ms)**, so the slowness is concentrated in file reading and script evaluation, not in core plugin work.

Environment

```yaml
SYSTEM INFO:
Operating system: Android 14 (vivo V2238)
Obsidian version: 1.13.8 (367)
API version: 1.13.8
Webview version: 153.0.8010.36
[PASTE FULL DEBUG INFO HERE — theme, snippets, restricted mode, language,
plugins installed/enabled]

Vault: 230 files. Plugins enabled: 9.

Full start-up time breakdown 
- Total startup time: 8,892ms
- Initialization: 1,270ms
  - Boot: 1,114ms
    - Response: 34ms
    - DOM parse: 276ms
    - Script evaluation: 804ms
  - Language: 33ms
  - App setup: 123ms
- Vault (230 files): 616ms
  - Configuration: 42ms
  - Reading files: 562ms
  - Loading file metadata: 10ms
  - Metadata listeners: 2ms
- Workspace (9 tabs, 8 deferred): 569ms
  - Components: 71ms
    - Managers: 34ms
    - Settings: 38ms
  - Appearance: 14ms
  - Managers: 106ms
    - Metadata types: 23ms
    - Secret storage: 65ms
    - Hotkeys & commands: 18ms
  - Layout: 368ms
    - Load layout: 363ms
    - Finalize: 4ms
  - Extra: 10ms
- Core plugins: 349ms
- Community plugins (9 active): 6,087ms
  - Smart Second Brain (2.2.0): 1,583ms
  - Notebook Navigator (3.4.1): 909ms
  - Editing Toolbar (4.1.4): 733ms
  - Pdftion (0.5.4): 510ms
  - Style Manager (0.5.0): 489ms
  - Quiet Outline (0.5.20): 277ms
  - Typing Assistant (0.3.0): 144ms
  - Google Drive Sync (3.1.1): 63ms
  - Cinematic Covers (0.5.4): 62ms
  - Other: 1,318ms

Additional information

Three separate issues, in the order I’d want them looked at.

1. The “Other” bucket makes the breakdown unusable for diagnosis (measurement bug).
1,318ms — 21.7% of all community-plugin time — is attributed to no plugin. Since the named plugins sum to 4,770ms and the section total is 6,087ms, this is real unaccounted time, not rounding. Whatever “Other” actually is (loader overhead, require-module resolution, deferred onload promises, promises not awaited by the profiler), it should either be attributed to the responsible plugin or broken into named sub-stages. Related: Plugin-loading profiler appears to give erroneous time for first plugin — the profiler has been reported as misattributing time before, and it was archived without a fix.

2. Reading files and script evaluation are the bottlenecks on mid-range Android hardware.
2.44ms per file on a 230-file vault, and 804ms of script evaluation, are both far above the flagship baseline on the same build. I understand this device is a low/mid-tier SoC, so some multiple is expected — but 8–9× per file is worth confirming, because a 230-file vault should be close to a fixed floor rather than scaling this steeply. If cold read cost is I/O-bound, the ask would be lazy/deferred file reading so the user can start typing sooner.

3. Deferred tab cost is moved outside the measurement rather than reduced.
“Load layout: 363ms” with 8 of 9 tabs deferred implies deferral isn’t buying as much as the label suggests; the remaining cost shows up as post-startup jank that the breakdown never reports.

Cross-references (I searched before posting; these are related but none of them cover the attribution problem on 1.13.8):

Happy to run any instrumentation, capture repeated cold starts, or provide my .obsidian folder (not the vault contents) if that helps.


---

## 3. Prior reports I found (cross-link these)

| Report | Platform | Relevance |
|--------|----------|-----------|
| [Android slow startup + misleading breakdown](https://forum.obsidian.md/t/obsidian-android-slow-startup-performance-and-misleading-startup-time-breakdown/95793) | Android, 1.8.3 | Closest match. Vault time was **higher** with plugins off (1,488ms) than on (373ms) — strong evidence the timer misattributes work [1](https://forum.obsidian.md/t/obsidian-android-slow-startup-performance-and-misleading-startup-time-breakdown/95793) |
| [Profiler gives erroneous time for first plugin](https://forum.obsidian.md/t/plugin-loading-profiler-appears-to-give-erroneous-time-for-first-plugin/35799) | Android/Windows | Establishes the profiler's attribution is already known-unreliable. Archived unfixed in 2022 [3](https://forum.obsidian.md/t/plugin-loading-profiler-appears-to-give-erroneous-time-for-first-plugin/35799) |
| [Reduce the time until the user can write](https://forum.obsidian.md/t/mobile-startup-reduce-the-time-until-the-user-can-write/57450) | Android | Long-running request; users on Pixel 7 report 39s + 49s on large vaults [1](https://forum.obsidian.md/t/mobile-startup-reduce-the-time-until-the-user-can-write/57450) |
| [[Bug] Android app extremely slow to launch](https://forum.obsidian.md/t/bug-android-app-extremely-slow-to-launch/28271) | Android | 2021, archived. Dev reply: "things are just slow on older Android phones… there isn't much we can do" [3](https://forum.obsidian.md/t/bug-android-app-extremely-slow-to-launch/28271) |
| [9s Android startup with Sync Engine](https://github.com/hesprs/sync-engine/issues/276) | Android 17, Pixel 9 | **Same build (1.13.8 / 367)** and Webview 153. My per-file baseline. Also shows a plugin inflating "Reading files" far beyond its own attributed 249ms [2](https://github.com/hesprs/sync-engine/issues/276) |
| [Windows Defender: cold first start](https://forum.obsidian.md/t/lately-plugins-take-a-lot-more-time-to-load-at-first-obsidian-startup-after-a-pc-boot-reboot-or-after-waiting-some-time-between-2-obsidian-launches/114182) | Windows | Same symptom (cold start ≫ warm start), different root cause — proves cold/warm distinction matters [2](https://forum.obsidian.md/t/lately-plugins-take-a-lot-more-time-to-load-at-first-obsidian-startup-after-a-pc-boot-reboot-or-after-waiting-some-time-between-2-obsidian-launches/114182) |

---

## 4. Honest read on your numbers

Your breakdown splits like this:

| Bucket | Time | Share |
|--------|------|-------|
| Community plugins | 6,087ms | 68.5% |
| Initialization | 1,270ms | 14.3% |
| Vault | 616ms | 6.9% |
| Workspace | 569ms | 6.4% |
| Core plugins | 349ms | 3.9% |

Two things to set expectations on:

**Most of this is your plugins, and the maintainers will say so.** Smart Second Brain (1,583ms) is by far the largest single line item. It's an AI/RAG plugin that embeds and indexes your vault, and its own docs warn that "the one thing to expect on a phone or tablet is that indexing a large vault is noticeably slower" [5](https://smartsecondbrain.dev/start/installation/). Notebook Navigator (909ms) also has a documented history of startup cost creeping up between versions [3](https://www.reddit.com/r/ObsidianMD/comments/1pyjqfl/notebook_navigator_20_for_obsidian_is_out_now/). Those two alone are 28% of your launch. Naming them in the report is honest and makes the rest of it more credible — I've kept them visible rather than hiding them.

**Your strongest Obsidian-side claim is the "Other: 1,318ms" bucket.** That is real, it is large, it is not attributable, and it defeats the purpose of the breakdown. The pre-plugin slowness is real too but more defensible for Obsidian, since your device appears to be a low/mid-tier SoC (a Geekbench entry for "vivo V2238" shows a MediaTek MT6769 at 1.8GHz with 3.67GB RAM [1](https://browser.geekbench.com/v6/cpu/429922), though V2238A is listed elsewhere as an iQOO Neo7 SE with a Dimensity 8200 [2](https://www.gsmchoice.com/en/catalogue/vivo/iqooneo7se/) — worth confirming which one you have, because it changes the argument a lot).

If the report comes back as "it's your plugins," the fastest real win is disabling Smart Second Brain and Notebook Navigator on mobile only and re-measuring — that should cut roughly 2.5s from your launch.

**Split option:** the forum prefers one bug per thread. If you want to maximise the chance of a `repro` tag, post only the "Other" bucket as its own thread (it's the cleanest, most falsifiable claim) and hold the pre-plugin-perf complaint back as a follow-up.
2

Ugh, nine seconds to start up would incredibly annoy me.

Every millisecond in the breakdown is attributable to a named component, so a slow launch can be traced either to a specific plugin or to Obsidian itself.

Resources get balanced across various things as they load. It increases optimization but makes it difficult or even inaccurate to attribute exact startup times to each loaded thing.

Deferring a tab removes its cost from startup rather than merely moving it outside the measured window.

Oh, does it not? I assumed it does.

On a small vault, the pre-plugin portion of startup should not dominate the launch.

The number of markdown files in a vault that seems small isn’t the only contributor to that portion of the startup time.

I know you made a bug report. But if you’re interested in more troubleshooting, there are things your GPT didn’t include—or maybe just weren’t in the part you pasted—and you hadn’t mentioned whether you tried. There seem to be quite a few reports lately of slow Android start-up. The below has fixed it for some folks:

Have you checked whether the .obsidian folder—or any other hidden folders you might have—has a large amount of seemingly excess files? For example, if a plugin made a ton of duplicates of a file. Making a backup and then clearing those out could help.

Have you looked for you own largest files and seen whether they’re contributing to slow load? If they are, you might still have to come up with a workaround, but at least you’d know what you’re working around.