[Date Prev][Date Next]
LDIF parser performance (was: write performance)
- To: Howard Chu <firstname.lastname@example.org>, openldap-devel@OpenLDAP.org
- Subject: LDIF parser performance (was: write performance)
- From: Michael Ströder <email@example.com>
- Date: Thu, 23 Nov 2006 15:56:05 +0100
- In-reply-to: <456589FE.firstname.lastname@example.org>
- References: <200608282343.k7SNhOjt061559@cantor.openldap.org> <44F3896A.email@example.com> <Pine.SOC.firstname.lastname@example.org> <44F64AB0.email@example.com> <4563F8F2.firstname.lastname@example.org> <4564DBF8.email@example.com> <4564E1C9.firstname.lastname@example.org> <4564E33F.email@example.com> <4564EA4D.firstname.lastname@example.org> <456589FE.email@example.com>
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060417
(Cc:-ed openldap-devel@OpenLDAP.org in opposite to our off-line
Howard Chu wrote:
> I'm wondering if it's worth the effort
> to rewrite the client's LDIF parser as I did for slapadd -q.
As I said I cannot test on the machine where I did the original tests.
But I tried to test OpenLDAP's LDIF parser with -n.
$ time ldapadd -f test.ldif -n
Now I have a small Python script which uses the module 'ldif' from
python-ldap for reading in the LDIF file. I've implemented module 'ldif'
in pure Python but off course the string module in the underlying Python
standard lib is implemented in C. And the Python runtime environment
does all the ugly memory management. :-)
$ time python count_members.py < test.ldif
I re-ran the tests twice, so test.ldif should have been in the
How does that sound to you? I'm not sure what different actions
ldapadd -n does in comparison to my simple script. But at least
count_members.py also reads the complete entries into a tuple containing
the DN as string and the entry as so-called dictionary.