openclaw - 💡(How to fix) Fix [Bug]: plugin manifest loader uses JSON5.parse for plain JSON files (~3x slower gateway boot) [2 comments, 3 participants]

Bug type

Bug (loadPluginManifest parses every plugin manifest with JSON5.parse, which is much slower than native JSON.parse and the manifests don't use any JSON5-specific syntax)

Beta release blocker

No

Summary

Plugin manifests are parsed with JSON5.parse. On this Pi that path runs ~10x slower than JSON.parse. With ~60+ plugins, the gateway spends 2-3 minutes parsing manifests on every boot. None of the bundled manifests on this install use JSON5-specific syntax.

Steps to reproduce

1. Run openclaw 2026.4.25
2. Restart the gateway
3. Watch the time gap from [gateway] ready to [whatsapp] Listening for personal WhatsApp inbound messages.

Expected behaviour

loadPluginManifest() should try the native JSON.parse first and fall back to JSON5.parse only if the file actually uses JSON5-specific syntax. Most manifests will go the fast path and skip JSON5 entirely.

Actual behaviour

dist/manifest-*.js loadPluginManifest() body:

let raw;
try {
    raw = JSON5.parse(fs.readFileSync(opened.fd, "utf-8"));
} catch (err) {
    return { ok: false, error: ... };
}

Every plugin manifest goes through the JSON5 parser regardless of content. The cost dominates gateway boot on slower hardware.

OpenClaw version

2026.4.25

Environment

Raspberry Pi 500 (Debian Trixie, aarch64). Gateway runs as a systemd user service. ~60+ bundled plugin manifests under dist/extensions/<plugin>/openclaw.plugin.json.

Logs, screenshots, and evidence

V8 --prof capture across a 4m28s [gateway] ready -> channels-up window. Top hot JavaScript functions:

   ticks  total  nonlib   name
  23337   8.5%   23.1%  JS: *default  json5/lib/parse.js:133:13   (entry point)
  22074   8.0%   21.8%  JS: *parse    json5/lib/parse.js:13:33    (parser core)
  14929   5.4%   14.8%  JS: *string   json5/lib/parse.js:570:12   (string token reader)
   1237   0.5%    1.2%  JS: *value    json5/lib/parse.js:238:11
   1145   0.4%    1.1%  JS: *read     json5/lib/parse.js:113:15
    282   0.1%    0.3%  JS: *loadPluginManifest  manifest-C0Wa8IEc.js:1013:28
    150   0.1%    0.1%  JS: *loadPluginManifestRegistry  manifest-registry-BeaRFaM3.js:317:36
    197   0.1%    0.2%  JS: *buildRecord  manifest-registry-BeaRFaM3.js:174:21

Combined, the json5 parse functions account for ~52% of all non-shared-library JavaScript CPU time. The rest of the profile is normal startup work (path resolution, module imports, etc.).

C++ side reflects the same pattern - lots of access() (file existence checks), getdents64 (directory enumeration), __open64_nocancel (manifest opens). Consistent with mass manifest scanning.

Wall-time impact on this install:

3x faster restart-to-channels-up after the patch.

Code pointers on this install:

• dist/manifest-C0Wa8IEc.js line 1036, loadPluginManifest() body, single JSON5.parse(...) call

Bundle filename will rotate per release; grep for JSON5.parse(fs.readFileSync(opened.fd.

Impact and severity

Affected: every gateway restart, and every CLI command that triggers the registry load (most of them on this install - boot-check, message send, cron list etc.). The slower the hardware, the bigger the slowdown; on a fast desktop machine it might be barely noticeable.

Severity: high on slow hardware (Pi class machines, low-end VPS), low on fast hardware. The 3x speedup is independent of CPU contention - even at nice +10 with no other processes competing, the same 3x gap exists.

Frequency: every gateway boot and every CLI command.

Additional information

I patched this on my box by replacing the JSON5.parse(...) call with a try-JSON.parse-first-then-JSON5.parse block. Two-line change in loadPluginManifest. Confirmed via wall-time and via --prof (json5 functions dropped out of the top 30 in the post-fix profile).

If any bundled manifest does need JSON5-specific syntax for a future feature, the fallback handles it. If none ever do, the JSON5 dep could be removed from the manifest loader entirely.