Graphtia documentation · reference

Adaptive resource management: Eco, Balanced and Fast

Choose Eco, Balanced or Fast. Explorer adjusts how much indexing work can run in parallel using the CPU capacity available to the process and current memory availability.

Choose how Explorer shares your machine

Explorer uses adaptive resource management to coordinate indexing work. Before starting more ordinary parser work, it checks available memory and reserves capacity for that work. If memory becomes scarce, it can reduce or pause new admissions while work already admitted finishes at a safe boundary. When conditions improve, it can gradually increase parallel work again.

Eco

A lower ordinary-parser ceiling: 25% of available CPU parallelism. Actual admitted work also depends on memory.

Balanced

An ordinary-parser ceiling of 50% of available CPU parallelism, with memory-aware admission.

Fast

An ordinary-parser ceiling of 75% of available CPU parallelism. More work is admitted only when memory and other limits allow it.

With eight available CPU threads, the current ordinary-parser ceilings are two workers in Eco, four in Balanced and six in Fast. These are calculated ceilings; actual concurrent work also depends on memory and the current indexing phase.

Choose how indexing shares your machine

Choose Eco, Balanced or Fast. Explorer uses the available resource context and the selected mode to constrain ordinary parser concurrency. Index progress and diagnostics describe what happened; mode percentages are not CPU utilization targets or RAM caps.

Resource modeEco · Balanced · Fast

Machine contextAvailable resources

Indexing workBounded concurrency

ProgressObserve the operation

DiagnosticsReview scope and limits

Published indexInspect its revision

Modes guide parser concurrency. They do not promise fixed CPU use, a memory ceiling or an indexing time.

What happens when memory becomes scarce

Indexing components share memory accounting for retained data and temporary work. Bounded queues, caches and disk-backed graph storage help keep work manageable. Where a component supports smaller safe units, it can fall back from a preferred allocation to its minimum. Other steps need an indivisible allocation and can still pause or report a resource limit; automatic splitting is not universal.

Adapt the work before starting another task

The scheduler considers task cost and available memory before admitting work. It can reduce or pause new tasks under pressure, then increase concurrency when conditions allow.

Pending workTasks to analyze

Cost + headroomEstimate required resources

Admit a full unitOr hold new work

Adjust concurrencyWorkers that may run

Finish the workRelease temporary data

Useful cachesRetained within limits

Fewer workers do not make an oversized task fit. Retained caches mean memory need not return to its starting level.

Why memory can remain after an index finishes

Explorer releases temporary indexing data when the worker finishes. Useful bounded caches can remain for later operations. On Linux with glibc, Explorer also requests the return of free memory pages to the operating system; this does not mean all memory returns to its starting level.

Worker concurrency and the memory required by one task are different controls. Each task needs its complete supported allocation before it starts. Reducing the number of workers does not make an oversized unit fit, and a product plan does not bypass resource admission.

Explore a large index through focused views

Navigation also works with scoped views. Explorer displays bounded projections of the stored graph and keeps query scope, revision and result limits explicit. A filtered or incomplete view is not the entire repository. Operations that provide a continuation can return more results within their documented scope; other operations require a narrower query.

Choose a profile for the work you are doing

Use Eco when you want a lower ceiling for ordinary parsing alongside other work.
Use Balanced as a middle setting for ordinary parsing.
Use Fast when you want a higher ceiling and have resources available. It does not guarantee a faster result for every project.

What the resource controls mean

These controls do not impose a hard limit on the application's total RAM use or guarantee that any repository will fit on a modest PC. Discovery and some later phases remain sequential, and language helpers have their own limits. More resources can allow more parallel work, but Fast does not guarantee a speedup for every project or phase.

Does Fast use all my RAM or CPU?

No fixed utilization target is enforced. Fast permits a higher ordinary-parser ceiling, while current memory availability and technical limits still govern admission. It is not a hard cap on total application RAM.

Will a more powerful PC index every project faster?

More CPU capacity and available memory can enable more parallel work. Results still depend on the codebase, language helpers, storage and sequential phases, so there is no universal speedup or completion-time guarantee.

Does a large index have to fit on the graph canvas?

No. The index is stored in blocks and explored through bounded projections. Visible counts describe the current view; filters, query limits and completeness information remain relevant.