-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Change WorkerTransport.{pageCache, pagePromises}
from an Array to a Map
#14355
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change WorkerTransport.{pageCache, pagePromises}
from an Array to a Map
#14355
Conversation
Given that not all pages necessarily are being accessed, or that the pages may be accessed out of order, using a `Map` seems like a more appropriate data-structure here. For one thing, this simplifies iteration since we no longer have to worry about/check if `pageCache`-entries are undefined (which will happen for *sparse* `Array`s). Of particular note is that we're no longer attempting to "null" the `pageCache`-entry from within the `PDFPageProxy._destroy`-method. Given that *synchronous* JavaScript will always run to completion[1] and that we're looping through all pages in `WorkerTransport.destroy` and immediately clear the cache afterwards, that code did/does not really make a lot of sense (as far as I can tell). Finally, also changes the `pageCache` to a *private* property since it's not supposed to be accessed from the "outside". --- [1] Unless there are errors, of course.
Given that not all pages necessarily are being accessed, or that the pages may be accessed out of order, using a `Map` seems like a more appropriate data-structure here. Finally, also changes the `pagePromises` to a *private* property since it's not supposed to be accessed from the "outside".
/botio test |
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.241.84.105:8877/d265567a867b1e3/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.193.163.58:8877/0fe5f0fdbf1ceaf/output.txt |
From: Bot.io (Linux m4)FailedFull output at http://54.241.84.105:8877/d265567a867b1e3/output.txt Total script time: 21.80 mins
Image differences available at: http://54.241.84.105:8877/d265567a867b1e3/reftest-analyzer.html#web=eq.log |
From: Bot.io (Windows)FailedFull output at http://54.193.163.58:8877/0fe5f0fdbf1ceaf/output.txt Total script time: 41.68 mins
Image differences available at: http://54.193.163.58:8877/0fe5f0fdbf1ceaf/reftest-analyzer.html#web=eq.log |
Looks good to me! |
Change
WorkerTransport.pageCache
from an Array to a MapGiven that not all pages necessarily are being accessed, or that the pages may be accessed out of order, using a
Map
seems like a more appropriate data-structure here.For one thing, this simplifies iteration since we no longer have to worry about/check if
pageCache
-entries are undefined (which will happen for sparseArray
s).Of particular note is that we're no longer attempting to "null" the
pageCache
-entry from within thePDFPageProxy._destroy
-method. Given that synchronous JavaScript will always run to completion[1] and that we're looping through all pages inWorkerTransport.destroy
and immediately clear the cache afterwards, that code did/does not really make a lot of sense (as far as I can tell).Finally, also changes the
pageCache
to a private property since it's not supposed to be accessed from the "outside".[1] Unless there are errors, of course.
Change
WorkerTransport.pagePromises
from an Array to a MapGiven that not all pages necessarily are being accessed, or that the pages may be accessed out of order, using a
Map
seems like a more appropriate data-structure here.Finally, also changes the
pagePromises
to a private property since it's not supposed to be accessed from the "outside".