Repository navigation
How Memory Is Measured
Memory is a feature of Nibtree (see Architecture), so the app measures itself in three ways: the readout in the status bar, a debug memory log in a file, and a live recording that AI tools and the command line tool can start. All three use the same function, memory::usage(). The user side is in Memory Use.
- Honest numbers. On macOS the interface runs in WebKit helper processes, and Activity Monitor charges them to the app. Counting only our own process would hide most of the memory.
- Causes, not just totals. A number alone does not say what made it grow. The memory log writes what was on screen and when scrolling started next to every change.
- Measuring while something happens. Fast scrolling or opening a big file makes short peaks that a 5 second poll misses. The recorder samples every 250 ms and takes marks.
sequenceDiagram
participant SB as StatusBar
participant CMD as commands/config.rs
participant MEM as memory.rs
participant OS as macOS libproc
loop every 5 s while the window is visible
SB->>CMD: memory_usage
CMD->>MEM: usage()
MEM->>OS: responsible pid of this app
MEM->>OS: list all pids, keep com.apple.WebKit helpers with the same responsible pid
MEM->>OS: proc_pid_rusage, phys_footprint of each
MEM-->>SB: MemoryUsage total, processes, approximate
end
memory.rs calls responsibility_get_pid_responsible_for_pid for our own process, then keeps every com.apple.WebKit* process with the same responsible process, and sums phys_footprint from proc_pid_rusage. That is Activity Monitor's "Memory" column. Each process gets a label: Nibtree (app), Web content (UI), Graphics and Networking.
When the app is started from a terminal (as bun tauri dev does), macOS makes the terminal the responsible process, so its other WebKit helpers would match too. Then approximate is set and a helper must also have started after our process (proc_start_abstime). The popover says so. Polling stops on visibilitychange while the window is hidden. On other platforms usage() returns zero and the item is hidden.
There is no "responsible process" on Windows. memory.rs takes a process snapshot (CreateToolhelp32Snapshot) and walks down from our pid: the msedgewebview2.exe browser the app started, then that browser's helpers (webview_processes, tested on every platform). Terminal shells and git are left out, as on macOS. Each process counts its private working set (PROCESS_MEMORY_COUNTERS_EX2), Task Manager's "Memory" column. The role comes from --type= on the helper's command line (webview_label): renderer is Web content (UI), gpu-process is Graphics, the network utility is Networking. Clear Cache stays macOS only, so the status bar hides its button elsewhere.
The popup also lists the memory of each terminal of the window, with what its shell started, and their sum. See How Terminal Memory Is Measured.
The popup also shows whether the GPU is used. probeWebgl (src/lib/ui/webglProbe.ts) asks the web view for a WebGL 2 context each time the popup opens, reads the renderer name, and releases the context with WEBGL_lose_context at once, so the check holds no GPU memory. Each terminal reports how it draws to gpuRenderers (src/lib/terminal/gpuRenderers.svelte.ts): TerminalAddons calls back with gpu when the WebGL addon loads, fallback when it fails or loses its context, and normal when GPU drawing is off; a closed terminal is forgotten. terminalDrawingSummary in gpuStatus.ts turns that and the two settings (GPU acceleration, font ligatures) into one line. GPU drawing costs about 70 MB for the first terminal (Measuring Setting Memory). The Graphics row above is the memory of WebKit's GPU process.
Settings, Automation, Memory log sets memoryLogEnabled, memoryLogIntervalMs (default 500) and memoryLogThresholdMb (default 5). src/lib/App.svelte passes them to memoryLog.configure (debug/memoryLog.svelte.ts), which invokes memory_log_configure.
flowchart LR
UI["memoryEvents.ts:<br/>view label, scroll start and stop"] -->|"memory_log_event"| Q["MemoryLog event queue<br/>(at most 200)"]
T["thread: usage() every interval"] --> D{"total changed by<br/>the threshold?"}
D -->|"yes"| F["append to memory.log"]
Q --> F
F --> R{"over 5 MB?"}
R -->|"yes"| Rot["keep it as memory.log.1,<br/>start a new file"]
memory_log.rs runs one thread while the log is on and none while it is off. A reading line is 2026-10-02T04:20:31.512Z total 400.0 MB (+50.0) | Web content 300.0 | ... in UTC; an event line is <time> event <label>. The window reports events through src/lib/debug/memoryEvents.ts: viewLabel describes the view, tab, Markdown mode, sidebar and bottom panel when they change, and watchScrolling reports "scroll start in markdown preview" and "scroll stop in ... (N events)" after 400 ms without scrolling (SCROLL_STOP_MS). The file is ~/.nibtree/logs/memory.log; the MCP tool read_memory_log returns its last lines.
start_memory_recording, read_memory_recording, mark_memory_recording and stop_memory_recording (in src-tauri/src/mcp/tools/recorder.rs) keep one recording in memory: samples every 250 ms by default, at most 7,200 samples and 200 marks, stopped after maxSeconds (600 by default) or when the MCP server stops. nibtree cli memory prints live readings from get_memory_usage instead. See How MCP and the CLI work and Debugging with MCP.
| File | What it does |
|---|---|
src-tauri/src/memory.rs |
macOS process memory, WebKit helper matching, labels |
src-tauri/src/memory_log.rs |
The log thread, line format, rotation, read_tail
|
src-tauri/src/commands/config.rs |
memory_usage, memory_log_configure, memory_log_event
|
src/lib/debug/memoryEvents.ts, memoryLog.svelte.ts
|
UI events for the log, the Settings state |
src/lib/views/MemoryStatus.svelte |
The readout and its popover |
src-tauri/src/mcp/tools/performance.rs, recorder.rs
|
get_memory_usage, sample_memory, the recorder |
Count the WebKit helpers. Most memory is the web view, and matching Activity Monitor lets users check the number.
Poll only while visible. A 5 second poll is cheap, and skipping it in the background keeps idle CPU at zero.
Log changes, not every reading. A line per reading would bury the few changes that matter; the threshold keeps the file short. 0 MB is there when every reading is wanted.
Nothing runs while it is off. The log thread and the recorder exist only while in use, and the log file is capped at two files of 5 MB.
The dev build found no WebKit helpers.
- The issue: the first memory probe found no WebKit helpers for the dev build, so only the app process was counted.
- Why it happened: the dev build starts from a terminal, and macOS made the terminal the responsible process, so no helper pointed at our pid.
- The fix and why we chose it: match helpers on whatever process is responsible for us, and when that is not us, also require a later start time and mark the result approximate. A Finder launch, what users run, stays exact.
-
src/lib/terminal/gpuStatus.test.ts: the GPU lines for every terminal state and setting, and the WebGL label. -
src-tauri/src/memory.rs:labels_web_kit_helpersandnames_webview2_processes_by_their_typecheck the role names,finds_only_the_webview2_processes_below_the_appthe Windows process walk;measures_the_current_process(macOS and Windows) checks that our pid comes first and has memory. -
src-tauri/src/memory_log.rs: UTC timestamps, the line format, and a run that logs changes and events, then stops. -
src/lib/debug/memoryEvents.test.ts:viewLabelnames the view, the tab file and the panels.scrollAreaNameandwatchScrollinghave no unit test yet. -
src-tauri/src/mcp/tools/recorder.rs: a recording with marks, new samples only, and stop.
- Update this page when
memory.rs, the log format or the recorder change, and Memory Use for visible changes. - The memory marks in Settings and how each setting was measured are in Measuring Setting Memory.
- Retake
status-bar.pngandmemory-log-settings.pngwhen they change (memory-log-settings.pngbelongs to the memory feature infeatures.json).
These pages are generated from docs/wiki. To correct something, open a pull request against the source file; edits made here are overwritten.
Using Nibtree
- Getting Started
- Welcome Screen
- Workspaces
- Files Panel
- File Operations
- File Icons
- Rounded Panels
- Editor and Tabs
- Pin Reorder and Wrap Tabs
- Single Tab Title
- Split Editor
- New File and Unsaved Changes
- Unload Hidden Tabs
- Editing Code
- Code Appearance
- Markdown Editor
- Image and PDF Preview
- Search Everywhere
- Recent Files
- Navigation Bar
- Find and Replace
- Changes and Commits
- Sign In Prompts
- Commit Box Layout
- Repository Actions
- Commit Options
- Ignoring Files
- Diffs
- Inline Diffs
- Staging View
- Revert a Change
- Resolving Conflicts
- Merge Tool
- Blame
- History and Log
- Merge Commits
- Branches and Tags
- Branches Popup
- Remotes
- Stashes
- Shelf
- Git Menu
- Git Dialogs
- Interactive Rebase
- Worktrees
- AI Agents
- AI Tasks
- AI Usage
- Keep Computer Awake
- Submodules
- Git LFS
- GitHub
- Git Console
- Terminal
- Terminal Features
- Scripts
- Navigation
- Menus
- Settings
- Settings Search
- Color Themes
- Settings Terminal and Automation
- Settings Files
- Updates
- Status Bar and Help
- Notifications
- Memory Use
- Clear Cache
- MCP and CLI
- Git Mergetool
- Keyboard Shortcuts
- Keyboard Shortcuts Editor
- Troubleshooting
- Troubleshooting Git
Developers
- Developer Guide
- Architecture
- Project Layout
- Backend
- How Folder Watching Works
- Folder Watching Bugs We Fixed
- How Workspace Files Work
- How the Preview Scheme Works
- Backend Services
- How Terminal Features Work
- Terminal Bugs We Fixed
- Frontend
- How the Rich Markdown Editor Works
- Rich Markdown Bugs We Fixed
- Git Menu Links
- Menu Keys and Routing
- Frontend Modules
- Blame Bugs We Fixed
- Project Color And Title Bar
- One Diff View
- Diff Bugs We Fixed
- Merge Tool Layouts
- Merge Tool Bugs We Fixed
- Color Theme Bugs We Fixed
- How the Connected Diff Works
- Rounded Panels Bugs We Fixed
- Update Bugs We Fixed
- Status Bar Bugs We Fixed
- MCP and CLI Bugs We Fixed
- Repository Actions Bugs We Fixed
- How the Changes Tab Works
- CodeMirror Patterns
- How the Cursor Works
- How Editor Features Work
- How the Path Bar Works
- Commands and Events
- Settings Reference
- Commands Workspace and Changes
- Commands Branches and Remotes
- Commands History and Extras
- Commands App and Tools
- Testing
- Test Suites
- Debugging
- Debugging with MCP
- Measuring Setting Memory
- How Terminal Memory Is Measured
- How Markdown Diagrams Work
- Releases and CI
- Publishing the Wiki
- Versioning and Changelog
- Browser Version Packages
- Browser Release Checks
- Docker Image
- Platforms and Signing
- Windows Support
- Windows Bugs We Fixed
- Windows MCP and CLI
- Docs and Screenshots
- UI Library
- UI Library MCP
- UI Library Bugs
- UI Library Migration
- Contributing
How features work
- Welcome screen
- Workspaces and folders
- Files panel
- File operations
- File icons
- Editor and tabs
- Pin, reorder and wrap tabs
- Single tab title
- Split editor
- New File and unsaved changes
- Unload hidden tabs
- Editing code
- Code appearance
- Markdown editor
- Image and PDF preview
- Search Everywhere
- Recent Files
- Navigation Bar
- Find and replace
- Changes and commits
- Sign-in prompts
- Commit box layout
- Repository actions
- Commit options
- Ignoring files
- Diffs
- Inline diffs
- Staging view
- Revert a change
- Resolving conflicts
- Merge tool
- Blame
- History and log
- Merge commits
- Commit tabs
- Branches and tags
- Branches popup
- Remotes
- Stashes
- Shelf
- Git menu
- Git dialogs
- Interactive rebase
- Worktrees
- AI agents
- AI usage
- Keep computer awake
- AI tasks
- Submodules
- Git LFS
- GitHub account
- Git Console
- Back and Forward
- Integrated terminal
- Scripts tool window
- Menu bar
- Settings
- Search in Settings
- Color themes
- Rounded panels
- Updates and release channels
- Status bar and help links
- Notifications
- Memory readout and memory log
- Clear Cache
- MCP server and command line tool
- git mergetool mode