A small memory-usage improvement for PDF documents opened from TypedArray-data

This patch contains a small optimization specifically for the case when `getDocument` is called with TypedArray-data. In that case we'll still hold onto that data, which could obviously be large, even after the "GetDocRequest"-message has been sent to the worker-thread.

In practice this will most likely not affect memory usage in any noticeable way, since the application calling `getDocument` will probably also be keeping a reference to the TypedArray-data. However, it seems like a good idea to ensure that the PDF.js API *itself* won't unnecessarily keep this data alive.
This commit is contained in:
Jonas Jenwald 2022-05-29 16:37:18 +02:00
parent 3fdf2ba4e3
commit 7e852851fd

View File

@ -513,6 +513,12 @@ async function _fetchDocument(worker, source, pdfDataRangeTransport, docId) {
}
);
// Release the TypedArray data, when it exists, since it's no longer needed
// on the main-thread *after* it's been sent to the worker-thread.
if (source.data) {
source.data = null;
}
if (worker.destroyed) {
throw new Error("Worker was destroyed");
}
@ -953,8 +959,8 @@ class PDFDocumentProxy {
}
/**
* @returns {Promise<TypedArray>} A promise that is resolved with a
* {TypedArray} that has the raw data from the PDF.
* @returns {Promise<Uint8Array>} A promise that is resolved with a
* {Uint8Array} that has the raw data from the PDF.
*/
getData() {
return this._transport.getData();