Parser rules improvements

Currently the parser sends a log line through a set of (regex) rules to identify it to know how to safely process it. The proposal is to replace the list with a circular buffer in hopes that for well formed log files, the "next" log line will be the "next" rule which should hopefully reduce the number of rules to try before getting a hit. The worst case is still run to failure, failure being, the log line being passed in isn't recognized.

[brunoborges]

/relevance-check

[github-actions]

Relevance Assessment: Likely Outdated

• Summary: The core concern of this issue — reducing the number of regex rules tried before finding a match — has been substantially addressed by the existing RuleSet class, which uses an LRU-based doubly-linked list instead of the proposed circular buffer. The specific circular buffer approach was not implemented, but an alternative optimization achieving the same goal is already in place.

• Evidence:

  • The RuleSet class in parser/src/main/java/com/microsoft/gctoolkit/parser/collection/ implements a custom doubly-linked list backed by a HashMap that moves the most-recently matched rule to the head of the list in O(1) time (via the select() method on line 154).
  • Both UnifiedGenerationalParser and UnifiedG1GCParser actively use parseRules.select(ruleToApply) to reorder rules on each match, ensuring frequently/recently matched rules are tried first.
  • A comment in RuleSet.java (line 157) notes: "attempting to sort by most often selected resulted in worse performance" — indicating that alternative optimization strategies were already evaluated and the current LRU approach was chosen deliberately.
  • The issue was created by a now-deleted user ("ghost") in October 2021, so the original author is unavailable for further discussion.
  • No PRs or commits reference a circular buffer approach, and no duplicate issues cover this topic.

• Recommendation: 🗄️ Consider closing — The underlying performance concern (reducing rule-matching overhead) has been addressed through the RuleSet LRU optimization, which achieves the same goal as the proposed circular buffer through a different mechanism. While the specific circular buffer idea was not implemented, the existing approach already ensures that for well-formed sequential logs, recently-matched rules float to the top and are tried first. The original author's account has been deleted, making further discussion on the original proposal unlikely. If there are remaining performance concerns with rule matching, a new issue with specific benchmarks would be more actionable.

Generated by Relevance Check Agent for issue #116