https://bugs.openldap.org/show_bug.cgi?id=9349
--- Comment #2 from Gabriel Buades gbuades@soffid.com --- You are right Howard.
I did something wrong while cleaning up the code to submit the patch. As you have pointed out, the comparison should be: + rc = ordered_value_match( &match, a2, + ap->a_desc->ad_type->sat_equality, 0, + &a2->a_nvals[k2], current, &text );
Anyway, let me test and check it. I will submit the patch again once it has been fixed.
Kind regards.
Gabriel Buades *Soffid* technical team leader ✉ gbuades@soffid.com ✆ +34-871962912 📱 +34-639660155 Skype: gbuadesr
*Please consider the environment before printing this email*
This email and any attachments are property of Soffid IAM SL. It may contain confidential or privileged information, so it is absolutely forbidden to copy, reproduce, publish and distribute their contents and the use of this material for any other purpose that is not strictly authorized, as stated at Intellectual Property and Data Protection laws.
El mié., 16 sept. 2020 a las 14:52, openldap-its@openldap.org escribió:
https://bugs.openldap.org/show_bug.cgi?id=9349
--- Comment #1 from Howard Chu hyc@openldap.org --- (In reply to Gabriel Buades from comment #0)
Taking advantage of the fact, that the values in the old and new
attributes
are ordered in the same way, I've build a patch to opmtimize this search process.
Now, the same operation takes 0.2 seconds, when it used to take 50s.
This can't be right:
for ( i=k=0; i < ap->a_numvals; i++ ) {char found = 0;BerValue* current = &ap->a_nvals[i];int k2 = k;for (k2 = k ; k2 < a2->a_numvals; k2 ++) {int match = -1, rc;const char *text;rc = ordered_value_match( &match, a2,ap->a_desc->ad_type->sat_equality, 0,&ap->a_nvals[i], current, &text );current is the same as &ap->a_nvals[i].
-- You are receiving this mail because: You reported the issue.