[
https://issues.apache.org/jira/browse/PDFBOX-6151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18080546#comment-18080546
]
Maruan Sahyoun commented on PDFBOX-6151:
----------------------------------------
[~tilman] [~lehmi] I've created an {{ArithmeticDecoderBenchmark}} class and a
{{benchmark-jfr}} profile in pom.xml using JMH and JFR. While
{{ArithmeticDecoder}} itself has little headroom for micro-optimisation, the
infrastructure proved its value immediately — JFR profiling revealed that
{{DefaultInputStreamFactory}} was responsible for 98% of apparent decoder
overhead. The benchmark serves as boilerplate for future investigations.
Benefits I'd see:
* The JFR-enabled {{benchmark-jfr}} profile in the pom is immediately reusable
for any future performance investigation in this codebase
* The {{MemoryCacheImageInputStream}} setup in {{@Setup}} is the correct
pattern for any decoder or related benchmark going forward
* The symbol count verification via {{@TearDown}} is a pattern worth
preserving — it caught a real issue (an infinite decode loop) during the
investigation
* The {{toByteArray()}} Java-8-compatible utility and the {{isEndOfStream}}
heuristic are small but non-obvious details that someone would have to
rediscover
Thoughts?
> Run serenity JBIG2 tests
> ------------------------
>
> Key: PDFBOX-6151
> URL: https://issues.apache.org/jira/browse/PDFBOX-6151
> Project: PDFBox
> Issue Type: Task
> Components: JBIG2
> Affects Versions: 3.0.4 JBIG2
> Reporter: Tilman Hausherr
> Priority: Minor
> Fix For: 3.0.5 JBIG2
>
> Attachments: image-2026-04-15-09-22-39-238.png
>
>
> Run the jbig2 files from the serenity tests by Nico Weber to see what happens.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
