Re: slapadd performance degradation from 2.3.43 to 2.4.12

[Ralf Haferkamp <rhafer@suse.de>]

Am Dienstag 25 November 2008 14:51:54 schrieb Ralf Haferkamp:
> Am Montag 24 November 2008 23:12:36 schrieb Hallvard B Furuseth:
> > Ralf Haferkamp writes:
> > > When linking against db-4.7.25 slapadd is still a little faster when
> > > the trickle-task is disabled: 15m19s (without the trickle-task) vs.
> > > 16m12s for the 500k Entries LDIF.
> >
> > Due to this mutex lock in bdb_tool_entry_put(), perhaps?
> >
> > 	if (( slapMode & SLAP_TOOL_QUICK ) && (( e->e_id & 0xfff ) == 0xfff )) {
> > 		ldap_pvt_thread_mutex_lock( &bdb_tool_trickle_mutex );
> > 		ldap_pvt_thread_cond_signal( &bdb_tool_trickle_cond );
> > 		ldap_pvt_thread_mutex_unlock( &bdb_tool_trickle_mutex );
> > 	}
> >
> > Weird code.  That's not the normal way to use a cond.  Why wait for a
> > mutex before signalling, when the code doesn't change any variable which
> > is tested around the cond_wait?
>
> Removing the _lock call brings the slapadd time down to 15m29s. So I guess
> that would be worth to fix. I'll commit it if nobody objects.
I re-ran the test multiple times and the results show that slapadd with the 
_lock/_unlock disabled gives pretty much the same speed as slapadd with the 
trickle-task disabled.

-- 
Ralf