BASALT · JOURNAL
Why PDF applications run out of memory on large files
Nearly every large file failure in a PDF application comes from the same decision, made early and rarely revisited: read the document into memory first, then work on it.
It is a reasonable decision. Holding the file makes everything afterwards simpler, and for the documents most developers test with, a few megabytes, it costs nothing. It only breaks when someone opens a real discovery production.
Buffering versus streaming
Buffering means reading the whole file into a block of memory. Peak memory is at least the size of the file, so a 2 GB document needs 2 GB before any work starts.
Streaming means reading the file in fixed size pieces and processing each piece as it arrives. Peak memory follows the size of the piece, not the file. A 4 MB chunk means about 4 MB of memory, whether the document is 40 MB or 4 GB.
The difference does not show up in testing unless somebody tests with a large file, which is why this failure reaches shipping products so often.
How to tell which one you have
Open your largest document and watch the application in Activity Monitor.
Memory climbing to roughly the file size, then staying there, means buffering. Your ceiling is available RAM and it will fail on something eventually.
Memory staying flat and modest regardless of file size means streaming. In a measured run on a 273 MB scanned document, peak resident memory was 89 MB, which is well under the file size and therefore evidence the file was never held whole.
Why it matters beyond crashes
Memory pressure does not always announce itself as a crash. Long before that, macOS starts compressing and swapping, and the application becomes slow in ways that look like a rendering problem rather than a memory one. Scrolling stutters, pages take a second to appear, and the obvious conclusion, that the document is too complicated, is wrong.
If a large document feels sluggish, check memory before optimising anything else.
The disk trade
Streaming usually means writing a working copy to disk rather than holding it in memory, which trades a memory problem for a disk one. That is a good trade, since disk is plentiful and its exhaustion is graceful, but it is worth knowing: opening a 2 GB document may need 2 GB of free space for the working copy, and that space should be released when the document is closed.
Frequently asked questions
Why does my PDF editor run out of memory?
Because it reads the whole document into memory before working on it, so peak memory is at least the file size. On a large scanned production that exceeds available RAM. Applications that read the file in fixed size chunks use memory proportional to the chunk, not the document.
How much RAM do I need to edit a large PDF?
With an application that buffers the file, at least as much as the document is large plus working space. With one that streams, far less: a measured run on a 273 MB scanned file peaked at 89 MB. The architecture matters more than the hardware.
Does a PDF application need disk space as well as memory?
Usually yes. Streaming a document generally means writing a working copy to disk, so opening a 2 GB file can require a similar amount of free space. That space should be reclaimed when the document is closed.
Why is my large PDF slow but not crashing?
Probably memory pressure short of exhaustion. macOS compresses and swaps memory before anything fails outright, and the result is stuttering that looks like a rendering problem. Check the application's memory use before assuming the document is at fault.
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.