BASALT · JOURNAL
Why page 500 should open as fast as page 1
There is a quick diagnostic for how well an application will handle long documents, and it takes about five seconds: open a long document, then jump to a page in the middle.
If that page appears as quickly as the first did, pages are rendered on demand. If it takes noticeably longer, or if the document took a long time to open and then everything was instant, pages were rendered up front.
Why on demand is correct
A thousand page document displayed on a screen shows one page. Rendering the other 999 produces bitmaps nobody looked at, at a cost in both time and memory, and the memory is the worse half: a letter page at screen resolution is a few megabytes, so a thousand of them is gigabytes of cached images for a document you have read one page of.
Measured on a 273 MB, 1,000 page scanned document: rendering the first page took 0.06 seconds and rendering page 500 took the same 0.06 seconds. Equal cost is the signature of on demand rendering. If pages had been rendered eagerly, the first would have been slow and the rest instant.
Where eager rendering comes from
Usually from thumbnails. An application that shows a page thumbnail sidebar has a reason to render every page, and if that work is done at open time rather than as the sidebar scrolls, opening a long document becomes expensive.
This is worth noticing because it is a feature causing the slowness, not a defect, and it often has a setting.
What good behaviour looks like
Opening is fast regardless of length. Scrolling renders as you go. Thumbnails fill in progressively rather than blocking. Memory rises with the pages you have actually looked at and gets released when you move on.
The trade you should not accept
Some applications achieve fast opening by rendering pages at very low resolution first and refining afterwards. That is a reasonable technique for viewing, and a bad one for redaction, because deciding what to remove from a page you cannot read clearly is exactly the wrong workflow. For document review, a page should be sharp before you are asked to act on it.
Frequently asked questions
Why is my PDF slow to open but fast to scroll?
Because pages were rendered when the document opened rather than as you reach them. That front loads the cost and consumes memory for pages you may never view. Rendering on demand keeps opening fast regardless of document length.
Should page 500 open slower than page 1?
No. With on demand rendering both cost the same, because each is rendered when requested. A measured run on a 1,000 page scanned document showed 0.06 seconds for both.
Why do thumbnails make large PDFs slow?
A thumbnail sidebar needs every page rendered. If that happens when the document opens rather than as the sidebar scrolls, opening a long document becomes expensive. It is often a setting worth turning off for large files.
Does rendering on demand use less memory?
Yes, substantially. Only the pages you have viewed occupy memory, and a well behaved application releases them as you move away, so memory reflects your reading rather than the document's length.
Doing it in Basalt
Basalt is a native macOS PDF toolkit with eighteen tools in one window. It opens large documents without loading them into memory, renders pages on demand, and copies files into its engine in fixed-size chunks, so peak memory follows the chunk size rather than the file size. Redaction destroys content rather than covering it, and an independent verifier re-opens every written file to prove the material is gone before the file is saved. A one time $29 licence covers up to three Macs, it is free for the first 24 hours, and the engine holds no network entitlement at all, which macOS enforces at the code-signature level. Download it at basaltformac.com.
Redaction that proves itself
Basalt destroys the content you mark, then re-opens the file it wrote and proves the content is gone before it saves anything. Your documents never leave your Mac.