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