René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"RuntimeHelpers.matches() recompiles regex Pattern on every evaluation","articleBody":"## Summary\n\n`RuntimeHelpers.matches()` calls `Pattern.compile(regexp)` on every CEL evaluation, even when the regex pattern is a constant string literal. This is a significant performance bottleneck for libraries like protovalidate-java that evaluate the same regex patterns millions of times.\n\n## Problem\n\nIn `RuntimeHelpers.java`, the `matches` method recompiles the regex on every call:\n\n```java\npublic static boolean matches(String string, String regexp, CelOptions celOptions) {\n    Pattern pattern = Pattern.compile(regexp);  // called every evaluation\n    ...\n}\n```\n\nIn protovalidate, CEL expressions like `input.matches('^0x[0-9a-f]{64}$')` are compiled into programs that are cached and reused. But the regex pattern itself is recompiled from the string on every `eval()` call. This applies to both runtime paths (`DefaultInterpreter` and `ProgramPlanner`), since both funnel through `RuntimeHelpers.matches()`.\n\n## Impact\n\nBenchmarks against real-world proto validation patterns show **38-82% end-to-end improvement** when patterns are cached:\n\n| Pattern | Unpatched | Patched | Improvement |\n|---------|-----------|---------|-------------|\n| Hex hash `^0x[0-9a-f]{64}$` | 4,683 ns | 2,897 ns | **38%** |\n| Blockchain address (alternation pattern) | 13,868 ns | 2,455 ns | **82%** |\n| UTXO pattern `^[0-9a-f]{64}:[0-9]+$` | 16,038 ns | 8,403 ns | **48%** |\n\nThe cost of `Pattern.compile()` scales with pattern complexity — alternation patterns like `^(0x[0-9a-fA-F]{40}|[1-9A-HJ-NP-Za-km-z]{26,64}|bc1[0-9a-zA-Z]{25,87})$` cost ~11μs per compile.\n\n## Context: cel-go already solves this\n\ncel-go has `MatchesRegexOptimization` in `interpreter/optimizations.go` which precompiles regex patterns at program creation time. protovalidate-go enables it via `cel.OptOptimize`. cel-java has no equivalent mechanism.\n\n## Suggested fix\n\nA minimal fix — add a `ConcurrentHashMap` cache to `RuntimeHelpers.matches()`:\n\n```java\n@SuppressWarnings(\"Immutable\")\nprivate static final ConcurrentHashMap\u003cString, Pattern\u003e COMPILED_PATTERNS =\n    new ConcurrentHashMap\u003c\u003e();\n\npublic static boolean matches(String string, String regexp, CelOptions celOptions) {\n    Pattern pattern = COMPILED_PATTERNS.computeIfAbsent(regexp, Pattern::compile);\n    // ... rest unchanged\n}\n```\n\nThis is a 3-line change. The cache is unbounded, which is safe because:\n- In practice, regex patterns in CEL come from compiled proto definitions (finite, small set)\n- If bounded eviction is desired, a `Caffeine` or LRU cache could replace `ConcurrentHashMap`\n\nA more sophisticated approach (matching cel-go's `MatchesRegexOptimization`) would precompile at program creation time in `ProgramPlanner.planCall()`, but that only helps the planner runtime path and doesn't fix `DefaultInterpreter`.\n","author":{"url":"https://github.com/devin-ai-integration[bot]","@type":"Person","name":"devin-ai-integration[bot]"},"datePublished":"2026-04-24T07:29:37.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/1038/cel-java/issues/1038"}