Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions .jules/bolt.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
## 2026-05-02 - Cache Reference Types During Parallel Plugin Execution
**Learning:** In performance-sensitive areas with parallel execution like `statusline.go`'s `runPlugin`, dynamically calling `colors.ColorMap()` allocates a new, relatively large map for every plugin invocation. Repeatedly allocating maps inside hot loops or goroutines creates unnecessary memory churn and GC pressure.
**Action:** Always cache static or read-only maps at the instance level (e.g., using `sync.Once` inside the struct) so they are only allocated once per rendering cycle, rather than re-creating them inside functions that execute concurrently across multiple routines.
12 changes: 11 additions & 1 deletion internal/statusline/statusline.go
Original file line number Diff line number Diff line change
Expand Up @@ -35,6 +35,8 @@ type StatusLine struct {
isIdle bool
bashPlugins []plugin.Plugin // Cached discovered bash plugins
bashPluginsOnce sync.Once
colorMap map[string]string // Cached color map
colorMapOnce sync.Once
Comment on lines +38 to +39
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Since the color map is derived from static constants and does not depend on any instance-specific state, it is more efficient to cache it at the package level rather than the instance level. This ensures the map is allocated exactly once for the lifetime of the process, regardless of how many StatusLine instances are created. This is particularly relevant if StatusLine is instantiated frequently (e.g., once per render cycle).

}

// New creates a new StatusLine renderer
Expand Down Expand Up @@ -634,7 +636,7 @@ func (sl *StatusLine) runPlugin(name string) string {
ContextWindowSize: sl.input.Context.ContextWindow,
},
Config: sl.getPluginConfig(name),
Colors: colors.ColorMap(),
Colors: sl.getColorMap(),
}

// Try native plugin first (much faster - no subprocess)
Expand Down Expand Up @@ -707,3 +709,11 @@ func (sl *StatusLine) getPluginConfig(name string) map[string]any {
pluginCfg := sl.config.LoadPluginConfig(name)
return map[string]any{name: pluginCfg}
}

// getColorMap returns the color map, creating it once if needed
func (sl *StatusLine) getColorMap() map[string]string {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

Sharing a single map instance across multiple plugins executed in parallel introduces a concurrency risk. In Go, maps are not thread-safe for concurrent operations if at least one of them is a write. While plugins are generally expected to treat the Colors map as read-only, a native plugin that accidentally modifies the map (e.g., to add a temporary color) will cause a fatal panic due to concurrent map access. Adding a warning comment helps clarify the expected usage for future native plugin developers.

Suggested change
func (sl *StatusLine) getColorMap() map[string]string {
// getColorMap returns the color map, creating it once if needed.
// WARNING: The returned map is shared across all plugins and must be treated as read-only
// to avoid concurrent map access panics during parallel execution.
func (sl *StatusLine) getColorMap() map[string]string {

sl.colorMapOnce.Do(func() {
sl.colorMap = colors.ColorMap()
})
return sl.colorMap
}
Loading