Skip to content

LibWeb: Avoid O(n²) behavior in NamedNodeMap::supported_property_names#8901

Open
officialasishkumar wants to merge 1 commit intoLadybirdBrowser:masterfrom
officialasishkumar:namednodemap-quadratic-fix
Open

LibWeb: Avoid O(n²) behavior in NamedNodeMap::supported_property_names#8901
officialasishkumar wants to merge 1 commit intoLadybirdBrowser:masterfrom
officialasishkumar:namednodemap-quadratic-fix

Conversation

@officialasishkumar
Copy link
Copy Markdown

NamedNodeMap::supported_property_names deduplicates attribute names while
preserving order. The previous loop called Vector::contains_slow() on
names at every iteration, which is O(n) in the size of names. With n
attributes the deduplication step is therefore O(n²).

Replace the linear scan with a HashTable<FlyString> that tracks which
names have already been appended. HashTable::set() returns
HashSetResult::InsertedNewEntry for first-seen names and
HashSetResult::KeptExistingEntry for duplicates, so a single O(1)
amortized call replaces the previous O(n) scan.

The hash table is pre-allocated to the same capacity as the attribute
list to avoid reallocation in the typical case where all attribute names
are unique.

Fixes #7980.

@ladybird-bot
Copy link
Copy Markdown
Collaborator

Hello!

One or more of the commit messages in this PR do not match the Ladybird code submission policy, please check the lint_commits CI job for more details on which commits were flagged and why.
Please do not close this PR and open another, instead modify your commit message(s) with git commit --amend and force push those changes to update this PR.

The function deduplicates attribute names in order. The previous
implementation used Vector::contains_slow() inside the loop, making the
overall complexity O(n²) in the number of attributes.

Replace the in-place linear search with a HashTable<FlyString> that
tracks which names have already been appended. Each set() call is O(1)
amortized, reducing the total deduplication step from O(n²) to O(n).

The pre-allocated hash table is initialised to the same capacity as
the attribute list so reallocation is avoided in the common case where
every attribute name is unique.

Fixes LadybirdBrowser#7980.
@officialasishkumar officialasishkumar force-pushed the namednodemap-quadratic-fix branch from 81451bf to d998aee Compare April 13, 2026 22:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

LibWeb: Accidentally-quadratic-behavior in NamedNodeMap

2 participants