Home » Networking » Net_LDAP » Bug #8489

[2006-08-17 13:21 UTC] b dot hallinger at skyforcesystems dot de

Description:
------------
In the CVS the shiftEntry() method is very slow and memory wasting.
However, the release 0.6.6 works fine. (the old Search.php's revision is 1.4.2.3, new one is 1.10)

Test script:
---------------
The exapmle server holds 262 Entries beginning with "cn=a".

$config['ldap'] = array(
'host' => 'ldap.example.com',
'dn' => 'cn=Admin,dc=example,dc=com',
'password' => 'mypass',
'tls' => false,
'base' => 'ou=sales,dc=example,dc=com',
'port' => 389,
'version' => 3,
'filter' => '(cn=*)',
'scope' => 'sub'
);

$ldap = Net_LDAP::connect($config['ldap']);
$search = $ldap->search('ou=sales,dc=example,dc=com','(cn=a*)',array('scope' => 'sub', 'attributes' => array('sn','gn')));

echo "<br>".$search->count().' entries found.';
$start=time()+microtime();

for($i=0;$i < $search->count();$i++){
$time=time()+microtime(); $elapsed=round($time-$start,4);
echo '<br>processing '.$i.'... ('.$elapsed.')';
$foo = $search->shiftEntry();
}

Expected result:
----------------
The Script should run fast.
Memory should be freed after the script finished.

Actual result:
--------------
Output with current CVS:
262 entries found.
processing 0... (0)
processing 1... (0.2438)
processing 2... (0.4711)
processing 3... (0.6958)
processing 4... (0.9269)
processing 5... (1.1554)
processing 6... (1.3804)
processing 7... (1.6072)
processing 8... (1.8252)
processing 9... (2.0485)
processing 10... (2.2678)
processing 11... (2.4859)
[output cut]
processing 258... (63.179)
processing 259... (63.397)
processing 260... (63.6745)
processing 261... (63.8852)

The Process hold 249 Megs of RAM. They are not freed after the test script run.

And output with 0.6.6:
262 entries found.
processing 0... (0)
processing 1... (0.0003)
processing 2... (0.0004)
processing 3... (0.0005)
processing 4... (0.0006)
processing 5... (0.0007)
processing 6... (0.0008)
[output cut]
processing 256... (0.0271)
processing 257... (0.0272)
processing 258... (0.0273)
processing 259... (0.0274)
processing 260... (0.0275)
processing 261... (0.0275)

Memory is not significantly altered.

[2006-08-17 14:01 UTC] b dot hallinger at skyforcesystems dot de

The problem is, that the $this->_ldap object is copied into every Entry object wich is time and memory consuming.
New Entry objects need to be build with a reference.

A Patch file is available at:
http://beni.skyforcesystems.de/patches/net_ldap/patch_bug_8489.diff

[2006-09-05 08:52 UTC] b dot hallinger at skyforcesystems dot de

I improved the patch file http://beni.skyforcesystems.de/patches/net_ldap/patch_bug_8489.diff in two ways:
firstly, a error similar to Bug #8286 that was introduced by the old patch is fixed and secondly, the patch is no longer in a false reverse format.