> 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
