Kind of improvement
chore
Affected area
hgraph
Summary
HGraph::GetMemoryUsage() already counts runtime scratch memory such as neighbors_mutex_ and pool_ (src/algorithm/hgraph/hgraph.cpp:650), but HGraph::GetMemoryUsageDetail() currently reports only serialize-size-style fields such as basic_flatten_codes, bottom_graph, route_graph, and __total_size__ (src/algorithm/hgraph/hgraph_serialize.cpp:400).
That makes allocator-reported growth from the visited-list pool hard to attribute when debugging search-time memory behavior. In particular, GetMemoryUsage() includes this->pool_->GetMemoryUsage() while GetMemoryUsageDetail() does not expose it as a separate field.
Suggested direction: add runtime memory fields such as visited_list_pool_runtime, neighbors_mutex_runtime, and optionally __runtime_total__, while preserving the current serialize-size breakdown for backward compatibility.
Expected benefit
Improve runtime memory observability and make it easier to reconcile allocator live bytes / RSS with VSAG's own memory reporting.
Benchmark evidence
Observed in a search stress test with a custom allocator instrumented by backtrace:
- the visited-list pool reached
live_count=34 and live_bytes=680026112
GetMemoryUsage() already accounts for pool memory, but GetMemoryUsageDetail() does not break that memory out today
References
- src/algorithm/hgraph/hgraph.cpp:650
- src/algorithm/hgraph/hgraph.cpp:653
- src/algorithm/hgraph/hgraph_serialize.cpp:400
- src/algorithm/hgraph/hgraph_serialize.cpp:419
- src/utils/resource_object_pool.h:102
Additional context
It would be best to keep serialize-size and runtime-resident-memory semantics distinct rather than mixing them into a single total with no attribution.
Related issues
Drafted with AI assistant: Codex:gpt-5
Kind of improvement
chore
Affected area
hgraph
Summary
HGraph::GetMemoryUsage()already counts runtime scratch memory such asneighbors_mutex_andpool_(src/algorithm/hgraph/hgraph.cpp:650), butHGraph::GetMemoryUsageDetail()currently reports only serialize-size-style fields such asbasic_flatten_codes,bottom_graph,route_graph, and__total_size__(src/algorithm/hgraph/hgraph_serialize.cpp:400).That makes allocator-reported growth from the visited-list pool hard to attribute when debugging search-time memory behavior. In particular,
GetMemoryUsage()includesthis->pool_->GetMemoryUsage()whileGetMemoryUsageDetail()does not expose it as a separate field.Suggested direction: add runtime memory fields such as
visited_list_pool_runtime,neighbors_mutex_runtime, and optionally__runtime_total__, while preserving the current serialize-size breakdown for backward compatibility.Expected benefit
Improve runtime memory observability and make it easier to reconcile allocator live bytes / RSS with VSAG's own memory reporting.
Benchmark evidence
Observed in a search stress test with a custom allocator instrumented by backtrace:
live_count=34andlive_bytes=680026112GetMemoryUsage()already accounts for pool memory, butGetMemoryUsageDetail()does not break that memory out todayReferences
Additional context
It would be best to keep serialize-size and runtime-resident-memory semantics distinct rather than mixing them into a single total with no attribution.
Related issues
Drafted with AI assistant: Codex:gpt-5