Updated webrev at https://cr.openjdk.java.net/~weijun/8162628/webrev.01/. The only change is using CertificateFactory.
I tried piped streams and it's even slower. --Max > On Aug 29, 2019, at 8:21 AM, Weijun Wang <weijun.w...@oracle.com> wrote: > > > >> On Aug 28, 2019, at 11:00 PM, Sean Mullan <sean.mul...@oracle.com> wrote: >> >> On 8/27/19 9:18 AM, Weijun Wang wrote: >>> Oops, sorry. I was calling "new X509CertImp" in PEM keystore and this has >>> not made use of the cache in X509Factory, and since my benchmark test loads >>> keystores hundreds of times it's certainly much slower than JKS. >>> I've disabled the cache and now PEM is only around 20% slower than JKS. I'm >>> sure some optimization will make it even smaller. >> >> Do you have an updated webrev? > > No. I tried some code changes but there is no performance enhancement. > > --Max > >> >> --Sean >> >>> --Max >>>> On Aug 22, 2019, at 11:47 PM, Weijun Wang <weijun.w...@oracle.com> wrote: >>>> >>>> >>>> >>>>> On Aug 22, 2019, at 10:40 PM, Sean Mullan <sean.mul...@oracle.com> wrote: >>>>> >>>>> On 8/14/19 10:07 AM, Weijun Wang wrote: >>>>>> The difference will be big. I've simplified the logic into >>>>>> 1. read bytes between first ": " and \r\n as alias >>>>>> 2. read bytes between first \r\n after first "-" and next "-" as a cert >>>>>> 3. goto 1 >>>>>> And I only store the cert bytes and do not create a Certificate until >>>>>> getCertificate() is read. I even haven't de-BASE64 them. >>>>>> Time spent is still ~2.5x of JKS (when reading from a >>>>>> ByteArrayInputStream). >>>>>> I guess the major reason is that there is no length field for the cert, >>>>>> so we must read-and-check all the time. >>>>> >>>>> Could you store the length as an attribute, perhaps? >>>> >>>> I'm reluctant to do that. This means people cannot edit the file with a >>>> text editor and have to use keytool to manage it. >>>> >>>> Of course, this file is still PEM and can be used by other tools, just >>>> that they should not try to modify it. >>>> >>>> I'll see if there are other ways to improve the performance. One way I'm >>>> thinking about is to read the first few bytes of a cert to find out the >>>> length (It's always also 30 82 AB CD...). >>>> >>>> Thanks, >>>> Max >>>> >>>>> >>>>> --Sean >>>>> >>>>>> --Max >>>>>>> On Aug 14, 2019, at 9:31 PM, Sean Mullan <sean.mul...@oracle.com> wrote: >>>>>>> >>>>>>> On 8/13/19 10:19 PM, Weijun Wang wrote: >>>>>>>>> I will also pass a pretty large cacerts with public CA and our CAs and >>>>>>>>> see wether your parser doesn't choke on it. >>>>>>>> PEM is certainly slower than JKS because of text reading and >>>>>>>> de-Base64. I'll see if I can make any enhancement. >>>>>>> >>>>>>> This is a bit of a concern for me. In the past, reading cacerts has >>>>>>> been a bit of a bottleneck and we have made some improvements over the >>>>>>> years such as: https://bugs.openjdk.java.net/browse/JDK-8129988 >>>>>>> >>>>>>> I would not want to see a regression in performance. >>>>>>> >>>>>>> --Sean >>>> >
