Performance and reliability
Measure parsing times with the inputs and runtime your application will use. Pattern length alone does not predict parsing time.
Built for live editing
regex101 parses patterns during editing. Each uncached call processes the full input.
Both parser functions cache results. Measure repeated calls separately from new inputs.
Measure these cases separately:
| Case | Purpose |
|---|---|
| Module load and first parse | Measure startup before the first result. |
| New patterns | Measure parsing across representative syntax. |
| Repeated pattern and options | Measure the repeated-call path. |
| Incomplete edits | Verify error recovery during typing. |
| Deeply nested or long patterns | Find practical input limits for your application. |
Record the package version, runtime version, hardware, flavor, flags, and input corpus with each result. Compare equivalent configurations.
Report typical and slow parsing times across the corpus, with cached calls measured separately.
Test coverage
Create a set of test patterns for your integration. Include the syntax your users need and errors your interface must explain.
For example:
- Valid groups, references, character classes, and quantifiers.
- Incomplete groups and character classes during typing.
- Unsupported flags for each selected flavor.
- Unicode cases relevant to your data.
- Substitution references with the associated pattern state.
Run these tests against the package version you will ship.
Validation model
The parser returns syntax tokens and a patternError status. Invalid input can still produce tokens for highlighting and diagnostics.
The parser does not compile or run the pattern. Verify matching behavior in the target engine, with the same flavor settings and representative text.
Parsing time is separate from matching time. A fast parse does not show that a regex is safe from excessive backtracking or ReDoS.