A small memory-usage improvement for PDF documents opened from TypedArray-data #14968
Conversation
…rray-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.
| * @returns {Promise<Uint8Array>} A promise that is resolved with a | ||
| * {Uint8Array} that has the raw data from the PDF. |
There was a problem hiding this comment.
While unrelated to the rest of the patch, this method should always be returning a Uint8Array hence it cannot hurt to be more specific in the JSDocs.
|
/botio unittest |
From: Bot.io (Linux m4)ReceivedCommand cmd_unittest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.241.84.105:8877/61fa8e8c496ff6f/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_unittest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.193.163.58:8877/c9b91cc4d3b6bdd/output.txt |
From: Bot.io (Linux m4)FailedFull output at http://54.241.84.105:8877/61fa8e8c496ff6f/output.txt Total script time: 3.30 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.193.163.58:8877/c9b91cc4d3b6bdd/output.txt Total script time: 7.17 mins
|
| if (source.data) { | ||
| source.data = null; | ||
| } | ||
|
|
There was a problem hiding this comment.
Could it make sense to transfer the data in the worker ?
There was a problem hiding this comment.
I though about that, but decided against doing it since that may end up breaking someone's code. Given that can't know how third-party users are invoking getDocument, it's thus possible that a user want to do something with the TypedArray after calling getDocument and it'd be surprising (and a breaking API-change) if we just transferred this data.
(And note that none of this applies to the Firefox PDF viewer either.)
This patch contains a small optimization specifically for the case when
getDocumentis 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
getDocumentwill 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.