You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
It's too slow. It was fast at the beginning, but after 40%, it's getting slower and slower. #1076
Hi @maintainers, I would like to work on this issue. Could you please assign it to me under GSSOC-2026? I will first reproduce the slowdown, investigate potential bottlenecks in the indexing pipeline, and then propose a fix. Thanks!
ananyasingh7052258502-coder commented on Jun 21, 2026
I would like to work on this issue. I noticed the indexing gets slower after 40% which looks like a performance bottleneck, possibly due to memory usage or inefficient batching.
Can you please assign this issue to me? I have experience debugging Python performance issues and I'm eager to contribute.
Closing in favour of #1168, which covers this with actual measurements.
#1168 reports the same user-visible symptom (indexing that starts fast then stalls) with the diagnosis attached: 346 s wall time and 2.2 GB peak RSS for 886 CALLS edges, with the hotspot named — tools/indexing/pipeline.py:249-272 calls build_function_call_groups and write_function_call_groupssynchronously insideasync def run_tree_sitter_index_async, blocking the event loop. Still true at HEAD.
Being straight about the merge: your report is a title, a screenshot and 0.4.13 — no backend, no repo size, no file count — so there is nothing here to add to #1168. It's also possible your slowdown-from-40% is a different phase than #1168's stall at 99% (per-file write amplification as the graph grows, rather than the post-processing stall).
If you can still reproduce on 0.5.4, please reopen with the backend, repo size and roughly where the percentage stalls. That distinction would be genuinely useful — I'd rather have two accurate issues than one vague one.
Activity
github-actions commentedon Jun 5, 2026
Hi! 👋 Join our CodeGraphContext Discord channel to collaborate: https://discord.gg/dR4QY32uYQ
gamana618 commentedon Jun 9, 2026
Hi @maintainers, I would like to work on this issue. Could you please assign it to me under GSSOC-2026? I will first reproduce the slowdown, investigate potential bottlenecks in the indexing pipeline, and then propose a fix. Thanks!
ananyasingh7052258502-coder commentedon Jun 21, 2026
Hi @maintainer,
I would like to work on this issue. I noticed the indexing gets slower after 40% which looks like a performance bottleneck, possibly due to memory usage or inefficient batching.
Can you please assign this issue to me? I have experience debugging Python performance issues and I'm eager to contribute.
Thanks!
Shashankss1205 commentedon Aug 2, 2026
Closing in favour of #1168, which covers this with actual measurements.
#1168 reports the same user-visible symptom (indexing that starts fast then stalls) with the diagnosis attached: 346 s wall time and 2.2 GB peak RSS for 886 CALLS edges, with the hotspot named —
tools/indexing/pipeline.py:249-272callsbuild_function_call_groupsandwrite_function_call_groupssynchronously insideasync def run_tree_sitter_index_async, blocking the event loop. Still true at HEAD.Being straight about the merge: your report is a title, a screenshot and
0.4.13— no backend, no repo size, no file count — so there is nothing here to add to #1168. It's also possible your slowdown-from-40% is a different phase than #1168's stall at 99% (per-file write amplification as the graph grows, rather than the post-processing stall).If you can still reproduce on 0.5.4, please reopen with the backend, repo size and roughly where the percentage stalls. That distinction would be genuinely useful — I'd rather have two accurate issues than one vague one.