Bug Description
basic-memory takes about 5 seconds to initialise on my system
Steps To Reproduce
Steps to reproduce the behavior:
- Install version: v0.20.3
- Run command: basic-memory --help
- Use tool/feature: cli
Expected Behavior
Should be faster I guess.
Actual Behavior
No errors. Just takes almost 5 seconds to initalise any command (other than --version)
Environment
- OS: Nixos
- Python version: 3.12.13
- Basic Memory version: v0.20.3
- Installation method: uv
Additional Context
Possible Solution
Claude did some probing and said this:
1. Slow startup (~4.5s for --help)
This is Python import time. The dependency tree includes heavy packages like onnxruntime, numpy, openai, sentence-transformers, etc. Even --help has to import the full module tree before Typer can render help. This is an upstream issue — basic-memory eagerly imports ML/embedding libraries at module level rather than lazily.
(reasoning)
The error is gone — good. Let's check if the slow startup is Nix-specific or inherent to basic-memory by profiling Python's import time:Interesting — import basic_memory itself is only ~1ms. The heavy imports happen when the CLI actually runs. Let me profile the full CLI:There it is. The total is ~255ms... wait, those are microseconds, so ~255ms? But the actual run takes 4.5s. Let me check if it's the entrypoint wrapper or onnxruntime:Big difference — 0.36s via Python directly vs 4.5s via the wrapped binary. The Nix wrapper is adding ~4 seconds. Let me check what the wrapper does:The inner wrapper imports basic_memory.cli.main, not basic_memory.cli.app. Let me check that:There's the culprit — basic_memory.cli.main takes 4.4s to import vs basic_memory.cli.app at 0.27s. Let me find out what's heavy in there:The breakdown:
basic_memory.api.app — 2.6s (imports FastAPI, all API routers, FastMCP server)basic_memory.cli.commands.status — 3.6s (imports the full API/MCP stack transitively)onnxruntime is likely hidden inside the prompt_router/embedding chain
This is not a Nix issue — it's an upstream problem. basic_memory.cli.main eagerly imports the entire API server, MCP tools, and embedding infrastructure just to render CLI help. This would be just as slow with pip.
The fix would be upstream: lazy-importing heavy modules (onnxruntime, fastmcp, the API app) so they're only loaded when actually needed. There's nothing we can do from the Nix packaging side to speed this up.
Bug Description
basic-memory takes about 5 seconds to initialise on my system
Steps To Reproduce
Steps to reproduce the behavior:
Expected Behavior
Should be faster I guess.
Actual Behavior
No errors. Just takes almost 5 seconds to initalise any command (other than --version)
Environment
Additional Context
Possible Solution
Claude did some probing and said this:
1. Slow startup (~4.5s for
--help)This is Python import time. The dependency tree includes heavy packages like
onnxruntime,numpy,openai,sentence-transformers, etc. Even--helphas to import the full module tree before Typer can render help. This is an upstream issue — basic-memory eagerly imports ML/embedding libraries at module level rather than lazily.(reasoning)
The error is gone — good. Let's check if the slow startup is Nix-specific or inherent to basic-memory by profiling Python's import time:Interesting —
import basic_memoryitself is only ~1ms. The heavy imports happen when the CLI actually runs. Let me profile the full CLI:There it is. The total is ~255ms... wait, those are microseconds, so ~255ms? But the actual run takes 4.5s. Let me check if it's the entrypoint wrapper or onnxruntime:Big difference — 0.36s via Python directly vs 4.5s via the wrapped binary. The Nix wrapper is adding ~4 seconds. Let me check what the wrapper does:The inner wrapper importsbasic_memory.cli.main, notbasic_memory.cli.app. Let me check that:There's the culprit —basic_memory.cli.maintakes 4.4s to import vsbasic_memory.cli.appat 0.27s. Let me find out what's heavy in there:The breakdown:basic_memory.api.app— 2.6s (imports FastAPI, all API routers, FastMCP server)basic_memory.cli.commands.status— 3.6s (imports the full API/MCP stack transitively)onnxruntimeis likely hidden inside the prompt_router/embedding chainThis is not a Nix issue — it's an upstream problem.
basic_memory.cli.maineagerly imports the entire API server, MCP tools, and embedding infrastructure just to render CLI help. This would be just as slow with pip.The fix would be upstream: lazy-importing heavy modules (onnxruntime, fastmcp, the API app) so they're only loaded when actually needed. There's nothing we can do from the Nix packaging side to speed this up.