On 31/8/05 3:08, Sagar R. Shah <[EMAIL PROTECTED]> wrote: > Hi Graham, > > I'm trying to bring a large Perl application out of the dark ages and as > part of this need to migrate from the existing Perl LDAP module (Ldapp - > based on Ldapc) to Net::LDAP. > > What I've found though is that the performance of Net::LDAP is around > seven times worse than the old solution - but I couldn't find any > references on Google about other people experiencing performance > problems > with Net::LDAP - so I assumed the problem was at my end. > > I decided to investigate further and profiled a script that obtained all > the LDAP attributes for a specific userid 500 times. Here's the profiler > output: > > $ dprofpp tmon.out > Total Elapsed Time = 27.01739 Seconds > User+System Time = 20.43654 Seconds > Exclusive Times > %Time ExclSec CumulS #Calls sec/call Csec/c Name > 27.7 5.668 55.339 13503 0.0004 0.0041 Convert::ASN1::_decode > 24.6 5.046 4.818 29009 0.0002 0.0002 Convert::ASN1::_decode_tl > 6.94 1.418 44.101 12502 0.0001 0.0035 > Convert::ASN1::_dec_sequence > 5.73 1.172 11.030 4505 0.0003 0.0024 Convert::ASN1::_encode > 5.23 1.069 0.962 13502 0.0001 0.0001 Convert::ASN1::_dec_string > 3.62 0.739 1.647 38 0.0194 0.0433 ResearchUtils::BEGIN > 2.83 0.578 6.301 3002 0.0002 0.0021 > Convert::ASN1::_enc_sequence > 2.69 0.550 0.542 1001 0.0005 0.0005 Convert::ASN1::asn_read > 2.50 0.510 0.410 10506 0.0000 0.0000 > Convert::ASN1::asn_encode_length > 2.24 0.457 14.619 1001 0.0005 0.0146 Net::LDAP::_recvresp > 2.03 0.414 19.719 500 0.0008 0.0394 > ResearchLDAP::getAttributes > 1.71 0.350 0.382 5000 0.0001 0.0001 > Net::LDAP::Entry::get_value > 1.61 0.330 0.318 1502 0.0002 0.0002 > Convert::ASN1::_dec_integer > 1.56 0.319 12.762 1001 0.0003 0.0127 Convert::ASN1::decode > 1.38 0.282 0.334 1 0.2822 0.3336 > Convert::ASN1::parser::yyparse > > Convert::ASN1 - or at least the way Net::LDAP uses Convert::ASN1 > seems to > be the "problem".
The worst problem's in Convert::ASN1::_decode_tl, which is called by Convert::ASN1::_decode. The decode_tl method is needed to decode the start of every "value", as BER precedes each value with a tag and a length (hence tl). These aren't simple bytes in the general case. I can't immediately see why this method's so slow. Is there a way to get the profiler to output information for each line in a method, instead of for the whole method? That might give (me) a clue. Cheers, Chris
