Very good job, phil. I will try your CCONV test on my linux machine to see if it is platform dependent ... or hw ?
Laurent Le mer. 3 oct. 2018 à 19:19, Philip Race <philip.r...@oracle.com> a écrit : > > > On 10/3/18, 1:15 AM, Laurent Bourgès wrote: > > Phil, > > If you look at the given pdf file, it has large images that exceed 2k so > such ones may be more costly to convert. > > > FWIW the one I profiled was by far the largest at 2577x1540. > The rest are more like 100x100, 200x200 or 500x500 - all approximations. > > > As jpeg decoder in openjdk11 is different than oraclejdk8, it may cause > more ColorConvertOp filter operations ... if color profiles are different. > > > That doesn't seem likely and in fact since I instrumented ColorConvertOp > in 8 & 11, I know exactly how many times it was invoked > by pdfbox, (11 times in both cases) and that all the image data is the > same. SRC and DEST are the same types etc. > > Also the version of LCMS is the same in 8 and 11 (v2.9). > > -phil > > > Anyway this performance is not related to Marlin renderer, so I can not > help much except in its diagnostic. > > Cheers, > Laurent > > Le mar. 2 oct. 2018 à 23:35, Philip Race <philip.r...@oracle.com> a > écrit : > >> I've spent some time examining what pdfbox is passing to ColorConvertOp >> It is called about 10 or 11 times in this test with images typically 1-2K >> in each dimension. >> The input image is a Custom BufferedImage which uses an ICC_ColorSpace >> constructed >> from a color profile file that is embedded in pdfbox which is an open >> source equivalent >> of what Acrobat uses. It has a 4 component raster and is opaque >> >> This is filtered into a 3 component standard INT_RGB ColorModel. >> >> I've distilled this down into a small program which has an copy of the >> method >> that is defined in pdfbox and is invoking the supposedly slow >> ColorConvertOp. >> >> So I believe this is all exactly what is happening in pdfbox. >> >> What I find is that it is actually much faster on JDK11 than JDK 8. >> >> prrubuntu:~$ ~/jdk-11/bin/java CConv >> 4881 >> prrubuntu:~$ ~/jdk8u181/bin/java CConv >> 12529 >> >> >> I can't say why that would be but the results are clear. >> So I am left to suppose that pdfbox really is doing something different >> in 8 vs 11. >> Or that this not the real problem. What do others see ? >> >> I've attached the program. The 1Mb color profile file can be got from the >> pdfbox sources. >> >> -phil. >> >> >> On 10/2/18, 9:35 AM, Laurent Bourgès wrote: >> >> Hi Daniel, >> >>> >>> Let's not compare apples and oranges. What I can see it takes the same >>> route and behave similarly. >>> >> >> I agree, I did not take enough time to get accurate profiles, sorry. >> >> >>> If you look at >>> http://uhash.com/java_reg/Call_Tree_java_8.html >>> http://uhash.com/java_reg/Call_Tree_java_11.html >>> >>> You can see that ConvertOp.filter takes 1.5s longer on Java 11. >>> >> >> I confirm: 1.8s vs 300ms. >> >> Philip, do you know what could have change in this 2d area ? >> >> I imagine ColorConvertOp delegates to native code so color profile (ICC) >> or hidpi support may have an impact here (or just compiler options may be >> different) ... >> >> If needed, I could profile native code using oprofile / perf. >> >> Laurent >> >>
