Runtime Performance

Runtime Performance

Studio is not the runtime

Conky Studio is an authoring tool, not a runtime interpreter.

The node graph you edit in Studio is a design document. When you Build (or use Live Preview, which uses the same pipeline), Studio converts that graph into a normal theme directory:

• conky.conf — window, update rate, hooks
• render.lua — draw and refresh logic
• scripts/ — sensors, weather, custom scripts, wrappers
• start.sh — launches Conky (and any background pollers)

After that, Conky Studio is not involved. The theme runs with stock Conky and those files. You can quit Studio, reboot, or copy the folder to another machine; performance is Conky’s, not Studio’s.

What “node count” does and does not mean

The number of nodes on the canvas does not map 1:1 to runtime cost.

Nodes are an editor abstraction. Codegen turns them into:

• Lua that reads sources (conky_parse, cache files, ${execi}, etc)
• One draw function per visible visual node
• Shell scripts only for external / custom sources that are actually needed

So runtime cost depends on what was generated, not on how crowded the graph looks.

Roughly:

Editor concept	Runtime effect
Many unwired source nodes	Usually not polled (nothing listens to them)
Visible visual nodes	Each contributes draw work every frame (or on the conf update cadence)
Bound sources / logic feeding visuals	Refresh + expression cost for those values
Custom Script in daemon mode	Extra background process + cache I/O
Custom Script in execi mode	Work inside Conky’s ${execi} interval
Heavy Custom Lua	Whatever Cairo/Lua you wrote — Studio does not optimize it away

A graph with 80 nodes where only 12 visuals are visible and five sources are wired can be lighter than a “simple” graph with one giant Custom Lua that redraws everything every tick.

What actually drives cost

Typical levers (same as any hand-written Conky theme):

1. Update interval / FPS — how often Conky and your draw hook run
2. How heavy render.lua is — gauges, graphs, text, images, Custom Lua
3. External commands — nvidia-smi, curl, sensors, custom scripts; interval and execi vs daemon matter
4. Images / surfaces — size, count, reload frequency
5. Desktop / compositor — ARGB windows, transparency, vsync

Studio’s job is to emit clear, structured files so those costs stay understandable and tunable—not to interpret the graph at 60 FPS.

Live Preview vs installed themes

Live Preview and Build & Install share the same codegen path. Preview is still “real Conky + generated files,” not a separate Studio renderer. What you see in preview is a good guide to installed performance, aside from normal differences (path layout, other processes, etc.).

Practical guidance

• Prefer native sources (${cpu}, ${memperc}, …) over shell when Conky already exposes the data.
• Use daemon polling for slow or heavy commands when the HUD redraws often; use execi for slow decorative data.
• Hide or delete visuals you do not need (visible / Layers) so they are not emitted into the draw path.
• Treat Custom Lua as hand-written performance: keep it lean if the HUD is large or high-FPS.
• After import of a legacy theme, rewiring Custom Lua Input 1–6 to Studio sources can replace redundant scripts and clarify what still runs at runtime.

Short summary

Conky Studio compiles your node graph into standard Conky assets. Runtime performance is governed by that generated Conky/Lua/script pipeline—not by Studio remaining open, and not by raw node count alone. Tune intervals, visibility, external scripts, and draw complexity the same way you would for any Conky theme.

---