[gnutls-devel] libtasn1 | Time to parse a few entries and a lot of entries is not linear (#51)

[Read-only notification of GnuTLS library development activities]

Thomas Karlsson created an issue: https://gitlab.com/gnutls/libtasn1/-/issues/51



## Description of problem:
The time to parse an CRL file is not linear to how many entries there are in the file.
I noticed this while using certtool to view a CRL file with approximately 56000 entries. I don't remember but it took a few minutes to parse the whole file.
The reason I'm posting this issue here is that with my limited skills traced it back to lib/decoding.c and to the function asn1_der_decoding2, but I'm not sure.

## Version of libtasn1 used:
4.19.0

## Distributor of libtasn1 (e.g., Ubuntu, Fedora, RHEL)
Debian bookworm

## How reproducible:

Steps to Reproduce:

 * Create a CRL with a lot of entries. I used crlbuilder by wbond. I can provide the script if requested.
 * time certtool --crl-info --infile root.crl.pem

## Actual results:
Here is a table with how many entries is the CRL, seconds it took (time certtool --crl-info --infile root.crl.pem) and per entry.
entr  sec.    per entry
4000  0.253s  0.063ms
5000  0.422s  0.084ms
6000  0.652s  0.108ms
7000  0.832s  0.119ms
8000  1.143s  0.143ms
9000  1.530s  0.170ms
10000 2.034s  0.203ms
11000 2.692s  0.245ms
12000 4.020s  0.335ms
13000 5.215s  0.401ms
14000 6.505s  0.465ms
15000 8.810s  0.587ms
16000 10.734s 0.671ms
17000 12.688s 0.746ms


## Expected results:
I don't know why but I think the time should be linear.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/-/issues/51
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20240626/cae00519/attachment.html>