Axel Howind created PDFBOX-5575:
-----------------------------------

             Summary: optimize LZWFilter
                 Key: PDFBOX-5575
                 URL: https://issues.apache.org/jira/browse/PDFBOX-5575
             Project: PDFBox
          Issue Type: Improvement
    Affects Versions: 3.0.0 PDFBox
            Reporter: Axel Howind
         Attachments: optimize_LZWFilter.patch

I ran the PDFBox tests with a profiler and saw that LZWFilter used quite a 
bunch of time, so I thought I might look at the code. I just looked at it 
totally out of context and tried to understand what is done there and what 
could be changed without altering results.

 * made the private mehtods static
 * changed the variable/method parameter 'earlyChange' from integer to boolean 
because I thought tha would be more readable
 * some minor tweaks
 * it looks like codeTable is initialized quite often and everytime, 256 length 
1 byte arrays are created, so I pre-allocate those byte arrays so that they can 
be shared by all code tables. [~tilman] I assumed the contents of the codeTable 
entries will not be changed, and my analysis of the code seems to prove that 
(also the passing unit tests). Just please have a look at this so I don't break 
anything.
 * it took me some time to fully understand what findPatternCode() does and why 
it checks the codeTable in reverse order. I more or less recreated that method 
from scratch and I think it should now always be faster: for patterns of length 
1 no iteration is done, and for longer patterns iteration stops once the 
correct entry is found. As this is the most notable change, please take a 
closer look. Unit tests pass.




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to