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:
parent
3fdf2ba4e3
commit
7e852851fd
@ -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();
|
||||
|
Loading…
x
Reference in New Issue
Block a user