On Apr 18, 2012, at 11:15 AM, Rich Megginson wrote:
Yeah, this particular operation has not been optimized. I believe SunDS added explicit optimizations for this particular case.
It is becoming painfully apparent as I write more detailed tests. 389 takes time to add or delete uniquemember values proportionate to the number of values being operated on and is using about twice as much time to delete as it does to add. Sun DS appears to have perhaps an almost O(1) algorithm in play on both adding and deleting values.
Is there perhaps some kind of referential integrity setting that is being used and forcing some kind of lookup of each value, one that we could perhaps turn off? We wouldn't need such a check because our metadirectory process handles the integrity/consistency checking already.