Re: Convert::ASN1 loading times

[John B. <jj...@be...>]

On Mon, 14 Aug 2000, Graham Barr wrote:

> John, this looks good and is certainly what I was thinking of.
> 
> Could you describe the format of your custom format. I cannot see
> exactly how it works.

Fair enough. Its pretty convoluted since I didn't initially allow for the
fact that the ASN.1 tree contains nodes which don't refer to tags (e.g.
the LDAPEntry definition, which is COMPONENTS OF). This was hacked on
later. I may need to rethink the whole thing :-)

> For example search for 0x80cadc0, which I think
> if supposed to be the root of the Filter, but I cannot see what I
> think is a definition.

That first (only) reference is a definition.

Pointers are defined in one of two ways. By occurring as the first or last
item on a line.

If the first item in a line is not a '_' it defines a new array reference
(blessed to be a Convert::ASN::parser). The contents of the referenced
array are the rest of the line. These correspond to the "cTAG cTYPE cVAR
cLOOP cOPT cCHILD".

If the last item in a line is not a '_' it either creates a new array
reference or adds to an existing one. In either case the reference is not
blessed and is stored as the cCHILD member of the containing array. The
contents of the referenced array are the nodes created by the following
lines (up to the next line with just a '-' on it).

The indentation is not used for parsing - but makes it more readable.

If the last item in a line is a '_' then the line was simple (no children)
and we stop recursion.

The case I initially didn't catch is the one now represented by a leading
'_'. This refers to a node in the tree which is a straight array ref, not
blessed to Convert::ASN::parser


There are currently bugs relating to the fact that for the cTAG member, I
map '' -> '0' -> (chr 0). I also introduce missing array elts as undef -
but I suspect that it OK. I don't fully understand your structures, I've
just tried to preserve them.


Comparing the Data::Dumper output of the tree as created by the real
Net::LDAP::ASN and as loaded from the file using the ->load() method show
a few differences, especially in the Filter definition. However, I'm not
sure that that isn't down to cosmetic reordering.


I wanted initially to order the output so that the reading order contained
no forward references. I then realised that this wasn't possible given the
self-referential nature of e.g. Filter. Thats when I gave up trying to
make it pretty :-)


If you haven't found it already, the ->save() method allows you to create
the .asn output.


If you like the idea I'll try and clean things up.


regards,

jb


PS. Some time ago you suggested I check out the Devel:: modules.  The
Devel::DProf module is cool. It shows up that
Net::LDAP::Schema::_get_one_word is a significant proportion (10-20%) of a
typical Schema load time. It is a one-liner used in two places, so
inlining is probably a good idea... are there any perl pragma's for this
yet or do we just cut and paste?