Improve performance of "SEC_ASN1Decode"

RESOLVED FIXED

Status

NSS
Libraries
P3
enhancement
RESOLVED FIXED
17 years ago
14 years ago

People

(Reporter: zhoubin, Assigned: Robert Relyea)

Tracking

({perf})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
In NSS,Many places call "SEC_ASN1Decode",so many many times are wasted,which 
debases performance greatly!!!This function is a lower layer fucntion,and 
should be run faster.
I think the reason is:The recursion is used when parsing the coding.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf

Comment 1

17 years ago
Thank you for the bug report.  Did you profile NSS and find that
it is wasting a lot of time in SEC_ASN1Decode?
Assignee: wtc → relyea
(Reporter)

Comment 2

17 years ago
In my application,I need process many certificates(get dn,subject,public 
key,private key) which cause call SEC_ASN1Decode so many times.And I test it by 
Rational Quantify,and find that SEC_ASN1Decode use a lot of time.
(Assignee)

Comment 3

17 years ago
The SEC_ASN1Decode is slow because it is complicated. The goal was to be able to
parse and ANS1 template thrown at it, while streaming. Nice and general case.
Dog slow with certificates. We get away with this most of the time because the
code tries to parse certificates only once (presuming you aren't calling
DecodeCertificate), and leave the cached parsed certificate in the temp db.

The 3.4 and 4.0 changes should streamline this a bit, including possibly using a
smaller, faster, simplier decoder and leaving the large one for parsing incoming
S/MIME messages.
Target Milestone: --- → 4.0

Comment 4

17 years ago
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee

Comment 5

16 years ago
*** Bug 150089 has been marked as a duplicate of this bug. ***

Comment 6

16 years ago
Moved Julien's comment from bug 150089:

One finding that came out of that defect is that SEC_ASN1_SKIP doesn't really do
the right thing and still consumes a significant amount of time proportional to
the size of the data block to skip. This is definitely an area where improvement
is possible.

Comment 7

16 years ago
Please see bug # 149816 , which contains a new, much faster ASN.1 DER decoder.
This is good only for non-streaming DER. BER or streaming isn't supported.

Updated

16 years ago
Blocks: 161215

Comment 8

16 years ago
This is half-fixed - all the DER cases are, that is. See bug 161215 .

The new SEC_ASN1_QuickDERDecodeItem could probably also be made to handle BER
relatively quickly, by making just one copy of the input. The one thing that
couldn't be added to it easily is streaming.
Changing target milesstone to --.  This isn't a stan bug.  It reports a bug 
in a 3.x interface.  

This bug suggests certain problems, but doesn't actually establish any of them
as proven, including:

a) re-decoding certificates repeatedly.  Caching (which I believe was added
after this bug was filed) should reduce this, unless we are redecoding the cert
when we already have a decoded copy sitting there.  All functions that return
parts of a cert should check to see if it is already deocded before decoding it
again.

b) not SKIPing over cert parts efficiently.  SKIP can only be efficient for 
definite length encoding.  I guess certs are usually DER, which inplies definite
length.  
Severity: normal → enhancement
Priority: -- → P3
Target Milestone: 4.0 → ---
I believe NSS is now using the new QuickDERDecoder for all cert processing.
So, can we mark this bug fixed?  

Comment 11

14 years ago
Yes. It should be noted that for situations where SEC_ASN1DecodeItem still has
to be used, ie. BER decoding, it helps performance quite a bit to use an arena
with a high chunk size. non-arena decoding needs to be avoided due to the leak
potential and low performance, but unfortunately the API supported it
historically, so we can't change that.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.