Skip to content

incorrect-bytes-format XSL transformation is too slow on large XMIR files #984

Description

@volodya-lombrozo

I'm getting performance warnings when running lints against eo-runtime:

[WARNING] XSL transformation 'incorrect-bytes-format' took 174ms, whereas threshold is 100ms

What happens: The selector //o[normalize-space(string-join(text(), '')) != ''] materializes and concatenates all text node content for every <o> element in the document. Then for each match, matches($bytes, '^(--|[0-9A-F]{2}(-|(-[0-9A-F]{2})+))$') applies a complex alternation regex. On large XMIR with many byte-carrying elements the string-join + normalize-space + regex evaluation adds up significantly.

What should happen: The transformation completes within the 100ms threshold. Using //o[text()] as the initial selector (elements with any text node) before materializing would narrow the candidate set. The regex itself could also be simplified.

Metadata

Metadata

Labels

bugSomething isn't working

Type

Fields

No fields configured for Bug.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions