DecodeStream currently initializes its |buffer| field to |null|, which
is reasonable, because lots of DecodeStreams never need to instantiate a
buffer. But this requires various special cases in the code.
This patch change it so DecodeStreamClosure has a single empty
Uint8Array which gets shared between all buffers upon initialization.
This avoids the special cases.
DecodeStream.prototype.ensureBuffer() is really hot, and this removes a
test from the fast path. For one 226 page scanned document this sped up
rendering by about 2%.
In src/core/obj.js, we convert a Ref to a string to index into a table like
this: 'R1.0'. This conversion is repeated numerous times.
This patch factors out the conversion into a new function.
Ref.prototype.toString().
This function can be called 100s of 1000s or even millions of times, and the
allocated return object accounts for 10% of all GC thing allocations for some
documents. It's easy to avoid, which reduces stress on the garbage collector,
and this patch does that.
PartialEvaluator.getTextContent() builds up textChunk strings 1 char at a time,
creating many 100s of 1000s of intermediate strings along the way. This patch
make it instead push chars to an array and then join them at the end, as we
have done in numerous other places.
This new function is much faster than ensureRange(pos, pos+1), which is a very
common case.
This speeds up the rendering of some test cases (including the Tracemonkey
paper) by 4--5%.
*Added AES128 Encryption
*Added AES258 Encryption/Decryption
*Added SHA256
*Added SHA512
*Added class to handle 8 byte integers and associated bit operations
*Added SHA384
*Added routines to handle new algorithm and perform PDF2.0 hashing.
Profiling showed that receiveAndExtend is frequently called with the length of
one bit. This happens for example in decodeBaseline.
For a single bit, the loop and shift in receive, as well as the shifts in
receiveAndExtend are overhead.
This shortcut manually calculates the shifts by either returning 1 or -1 from
receiveAndExtend by reading the bit and deciding on the return value.
While it comes with an overhead for each non-one length, the speedup is at about
10% in the hot parse/decode path.
This change makes the 4 conversion loops look the same.
It optimizes access of the array length and access of the property
numComponents, which is known to be constant.
Nicholas Nethercote
fkaelberer
Jonas Jenwald
pramodhkp
Fabian Lange
Yury Delendik
Tim van der Meij
Daniel West
p01
koderok