Page-object reverse index

HotPDF maintains a document-local reverse index from page object identity to zero-based page position

Lookup behaviour

GetPageArrIndexForObjectNumber accepts a PDF object number, whilst GetPageArrIndexForObject accepts either a resolved page object or a THPDFLink

Both methods return -1 when the value does not identify a current page

If malformed input exposes the same identity more than once, the first page in document order wins deterministically

Construction and invalidation

The index is built lazily on the first lookup and uses separate open-addressed maps for object numbers and resolved object pointers

Loading, resetting, adding, deleting, copying, replacing, moving, reversing, swapping, reordering, or reconciling pages invalidates the maps

The next lookup rebuilds both maps from the current page order, so mutation cost does not include an eager index rebuild

Performance and ownership

The maps keep their load factor below one half and provide expected constant-time lookup after an O(page count) build

A regression gate performs one million lookups after mutation in a 100,000-page table and requires p95 latency below 5 microseconds on both supported Windows targets

The index stores non-owning object pointers and is released with its THotPDF instance

Do not mutate a THotPDF instance concurrently with page lookup because loaded-document graph mutation remains caller-serialised