Optimise book system: lazy-compile on open instead of batch-compiling at boot#955
Open
JSKitty wants to merge 1 commit intoTurningWheel:masterfrom
Open
Optimise book system: lazy-compile on open instead of batch-compiling at boot#955JSKitty wants to merge 1 commit intoTurningWheel:masterfrom
JSKitty wants to merge 1 commit intoTurningWheel:masterfrom
Conversation
Previously, all 34 books were compiled (text reflow + pagination) at startup. This involved reading every .txt file, parsing a 192KB JSON cache for byte-for-byte comparison, and either loading or recompiling all books before the main menu appeared. The entire process took roughly 3 seconds on every boot, wasting CPU cycles on content the player may never read. This refactor defers compilation to the moment a book is actually opened. At startup, createBooks() now only discovers filenames via PhysFS without reading any file contents. When a book is opened for the first time, compileBook() loads that single .txt file, normalizes whitespace, reflows text to fit page dimensions, and paginates. The compiled pages are cached in memory, so subsequent opens of the same book are instant. Performance results (MacBook Pro M4 Max, 128GB): - Boot time reduced by ~3 seconds (book init now runs in under 1ms) - Individual book compilation is imperceptible (microseconds per book) - No observable hitch when opening any book, including multi-page ones Code reduction: - Removed ~620 lines of cache management (readCompiledBooks, writeCompiledBooks, booksRequireCompiling, readBooksIntoTemp) - Removed compiled_books.json read/write/validation infrastructure - Removed rapidjson/filereadstream.h dependency from book system - Added ~45 lines for the lazy compilation path The change is platform-agnostic with no preprocessor conditionals. Book indices, mod reload (physfsReloadBooks), banned book filtering, and multiplayer sync are all unaffected since allBooks is populated in the same sorted order and numbooks is set at discovery time.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Details
I was curious at why Barony seemed to load relatively slowly (for the size and amount of assets in the game), I took a little dive and compiled it on MacOS, realised that Book Compilation took a relatively large chunk (around 50%!) of boot time, this was consistent over both Windows and MacOS in my testing.
I've implemented lazy-loading (or "lazy compiling") in to Barony, this completely eliminates the startup cost (even the compiled book cache still uses relatively high resources), removes CPU cycle wastage on books that people potentially will never read in that session, and also vastly reduces the amount of
book.cppcode: faster, cleaner, leaner.Mods that add books will not be affected, and updates that add/edit/remove books will also not be affected, this system has less moving parts, and is therefore even more reliable than the previous implementation, while granting massive performance gains.
Copy-Pasted Commit Message for maintainer convenience:
Previously,
createBooks()read all 34 .txt files at boot, compared thembyte-for-byte against a JSON cache, and either parsed the cache or recompiled
every book before the main menu appeared. This took ~3 seconds every launch.
Now
createBooks()only discovers filenames via PhysFS (no file reads).When a book is opened for the first time,
compileBook()loads and paginatesthat single book on demand. The compiled pages stay cached in memory, so
reopening is instant.
Book indices, mod reload, banned book filtering, and multiplayer sync are
all unaffected since
allBooksis populated in the same sorted order.Test plan
numbooks= 34