Right-size the map array in PartialEvaluator_readToUnicode

[Snuffleupagus]

We can avoid a lot of intermediate resizings, by directly allocating the required number of elements for the map array.

[Snuffleupagus]

/botio test

[pdfjsbot]

From: Bot.io (Linux)

---

Received

Command cmd_test from @Snuffleupagus received. Current queue size: 0

Live output at: http://107.21.233.14:8877/2a689655046a25f/output.txt

[pdfjsbot]

From: Bot.io (Windows)

---

Received

Command cmd_test from @Snuffleupagus received. Current queue size: 0

Live output at: http://107.22.172.223:8877/0d7a59a03a7d9e4/output.txt

[pdfjsbot]

From: Bot.io (Linux)

---

Success

Full output at http://107.21.233.14:8877/2a689655046a25f/output.txt

Total script time: 19.15 mins

• Font tests: Passed
• Unit tests: Passed
• Regression tests: Passed

[pdfjsbot]

From: Bot.io (Windows)

---

Success

Full output at http://107.22.172.223:8877/0d7a59a03a7d9e4/output.txt

Total script time: 19.50 mins

• Font tests: Passed
• Unit tests: Passed
• Regression tests: Passed

[CodingFabian]

Looks good to me

(took me however a moment to realize 0x10000 is 0xffff +1 so the array can hold the 0 - 0xffff elements :-))

[timvandermeij]

@brendandahl Could you review/merge this one?

[brendandahl]

It's been awhile since I looked at the state of things in spider monkey, but it use to not matter if you passed in the array length, a dictionary would still be created, which performs the same as []. To make it faster you have to fill in all slots to make it a dense array. There are trade offs though, it takes time to make it dense, so its really only worth it if the array accessed a lot.
https://github.com/mozilla/pluotsorbet/blob/master/utilities.ts#L169

[Snuffleupagus]

I know that @nnethercote has done something similar previously, see e.g. PRs #5096 and #5191 which served as inspiration for this patch, since it should reduce the amount of memory allocations required.

Although in both those cases all the Array elements are accessed in the subsequent code, so I'm not sure if/how this comparison is relevant for this patch.

[brendandahl]

Yeah, so it looks like the length is used now if you follow the creation from https://dxr.mozilla.org/mozilla-central/source/js/src/jsarray.cpp?from=js%3A%3AArrayConstructor#3182-3226

One thing I'm not sure about though is if it's worth it, the pdf.js code has a comment about the cmap possibly being sparse so the map would also be sparse. Any idea if they usually are sparse?

[Snuffleupagus]

One thing I'm not sure about though is if it's worth it, the pdf.js code has a comment about the cmap possibly being sparse so the map would also be sparse. Any idea if they usually are sparse?

When debugging/fixing font issues, I recall having seen cmaps that are either: dense, sparse, or somewhere in between. In general it might be difficult to answer this accurately, since it can vary a bit, but it seems to me that many cmaps do tend to fall in the "denser" end of the spectrum.