Dramatic pagination performance reduction when creating TOC with page numbers

[depth42]

Describe the bug
I am working on a user manual with more than 100 pages which gets paginated with vivliostyle. Without a table of contents, the pagination is complete in under 10 seconds in Safari on my Mac Studio. When I activate the TOC, the pagination performance dramatically degrades and it takes 40 seconds to paginate. This smells like an unwanted O(n^2) behaviour somewhere in vivliostyle.

To Reproduce
Paginate the attached user manual "Manual.html" with vivliostyle v2.40.0 and measure the time.

By default, the TOC is active. If you want to disable it for speed comparison, add style="display:none" to the TOC div in line 57 of Manual.html.

TOCPerformance.zip

Expected behavior
Paginating with a TOC should not degrade the performance so much.

Desktop (please complete the following information):

• OS: macOS 26.1
• Browser Safari 26.1

[u1f992]

I investigated the renderSinglePage call count with your sample:

Condition	Call Count	Pages	Re-renders
With TOC	215	148	67
Without TOC	155	155	0

The current behavior seems O(n), approximately one re-render per target-counter() reference.

It is natural behavior for typesetting time to increase when adding cross-references. For example, as a precedent, TeX's cross-references aim to converge by re-typesetting the entire document, and the number of iterations can theoretically be infinite.

That said, there is room to improve the page re-rendering strategy for better performance, such as lazy updates, batch processing, or other algorithmic improvements.

[u1f992]

Would something like perf/batch-target-counter-rerender work? It achieved about 40% improvement, but may be too simplistic and lack sufficient consideration.

[depth42]

I don't think the re-rendering explains all what's happening. When you activate the the debug flag of the CoreViewer you can observe that the TOC page is not only re-rendered often, but each re-rendering is also painfully slow.

[u1f992]

Indeed, the slowness of the re-rendering process itself may also be an issue.
However, given the inherent uncertainty of reference resolution and re-rendering in general (which could potentially invalidate all other pages), I'm afraid I wouldn't immediately think of a good idea to make the re-rendering process itself smarter...

The branch mentioned above should succeed in reducing the overall time by reducing the number of re-renders itself.
Typically, for a dot-leadered table of contents, I believe it should complete in 2 passes, since leaders absorb changes in length.

[depth42]

Sounds good. This should bring a decent speed up for documents with lots of references.

[u1f992]

I've been investigating this further and found that the batch processing approach which I implemented has a fundamental limitation.

The core issue seems to be a circular dependency: page layout depends on content, but target-counter() content depends on page layout. A proper solution would require a TeX-like approach where the entire document is re-typeset from scratch until convergence, which needs deeper refactoring of the rendering pipeline.

I'll leave the branch for now in case it's useful as a starting point for anyone who wants to tackle this.