perf: O(1) else-token lookup in Java analyzer via child(3) instead of find()#477
Merged
askpt merged 2 commits intoJul 26, 2026
Merged
Conversation
… find() In Java's tree-sitter AST an if_statement with an else clause has a fixed structure: [0]=if, [1]=condition, [2]=then-body, [3]=else-keyword, [4]=else-body. Replace the O(n) Array.prototype.find() scan with a direct O(1) child(3) lookup, eliminating a closure allocation and linear scan over every if_statement's children list when an else clause is present. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…-d2e3d15df700612d
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #477 +/- ##
=======================================
Coverage 81.43% 81.43%
=======================================
Files 13 13
Lines 4346 4347 +1
Branches 440 439 -1
=======================================
+ Hits 3539 3540 +1
Misses 806 806
Partials 1 1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Contributor
There was a problem hiding this comment.
Pull request overview
This PR optimizes Java cognitive complexity analysis by replacing a linear scan over if_statement children to locate the else keyword with a direct indexed lookup, reducing per-node overhead during traversal.
Changes:
- Replaced
node.children.find(...)withnode.child(3)when retrieving theelsetoken for Javaif_statementnodes that have an else branch. - Kept a defensive type check (
elseToken.type === "else") before recording the “else clause / else if clause” complexity detail.
askpt
deleted the
repo-assist/perf-java-else-token-O1-20260726-d2e3d15df700612d
branch
July 26, 2026 13:23
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 This pull request was created by Repo Assist, an automated AI assistant.
Summary
Replaces a linear
Array.prototype.find()scan with an O(1) indexedchild(3)lookup when locating theelsekeyword in Javaif_statementnodes.What Changed
src/metricsAnalyzer/languages/javaAnalyzer.tsIn Java's tree-sitter AST, an
if_statementwith an else clause always has this fixed child layout:ifkeywordelsekeywordBefore:
node.children.find((c) => !c.isNamed && c.type === "else")elseBranchNodeis null (no else clause)After:
node.child(3)+ type guardelseToken.type === "else") retained for safetyThis path runs for every
if_statementwith an else clause during analysis. In files with many if/else chains, this eliminates repeated closure allocations and scans.Test Status
Warning
Firewall blocked 1 domain
The following domain was blocked by the firewall during workflow execution:
releaseassets.githubusercontent.comSee Network Configuration for more information.
Add this agentic workflow to your repo
To install this agentic workflow, run