release: PureXML 0.4.5 (#307)

Stamp the attribute-index and sibling-axis quadratic fixes as 0.4.5: sorting an
element's attributes into document order was quadratic in the attribute count,
and the following-sibling/preceding-sibling axes scanned a wide parent's child
list per context node. Both now use the shared sibling-index cache (and the
sibling axes fuse the node test). Also correct the changelog: these two entries
were mistakenly grouped under the released 0.4.4 heading.
This commit is contained in:
Mihaela Mihaljevic 2026-06-25 23:08:02 +02:00 committed by GitHub
parent b104723fed
commit f6802c1baf
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194

View File

@ -7,7 +7,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
## [Unreleased]
## [0.4.4] - 2026-06-25
## [0.4.5] - 2026-06-25
### Fixed
@ -15,6 +15,10 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
- Sorting many attribute nodes from the same element into document order is no longer quadratic in the attribute count. An attribute's document-order key bands by its index among its owner's attributes, which was found by a linear scan of the attribute list on every attribute, so sorting an element's K attributes was O(K^2). The index now comes from a cached per-owner name-to-index map (built once on the second lookup, mirroring the sibling-index cache). The order is unchanged. Sorting the attributes of an 8000-attribute element drops from about 0.18 s to about 0.01 s (~16x), and the cost is now linear. Guarded by `AttributeDocumentOrderTests`.
## [0.4.4] - 2026-06-25
### Fixed
- The `following` and `preceding` axes no longer rebuild the whole document node list and linearly search it on every context node, which made them quadratic over many context nodes. They now share a per-evaluation cache of each document's ordered node list and a node-to-index map (the document does not change during evaluation), so the list is built once and a node's position is an O(1) lookup; `following` additionally skips the context's contiguous subtree by index arithmetic rather than filtering every descendant out. The step's node test is fused into the walk, so a node the test rejects is never copied out of the shared list (only the matches are materialized). The selected nodes and their order are unchanged. A 200-context `following::` query over a 20k-element document drops from about 16 s to about 6 s. Guarded by `FollowingPrecedingAxisTests`.
## [0.4.3] - 2026-06-25