Quanah Gibson-Mount wrote: Any info about the infra you are running this test ? Thanks ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org

Quanah Gibson-Mount writes: I'm tempted to backport the patches to 2.3 so we can compare with what 2.3 could have been:-) Maybe --disable-debug is a place to fetch some speed. If it makes a enough difference from loglevel 0, it might be an idea to disable _some_ loglevels and some asserts in the default build. After we've done something about that broken log system of course - IIRC today one needs to turn on massive logging to get certain error messages. -- Hallvard

Quanah Gibson-Mount writes: Right, but without --disable-debug that still executes the Debug() and assert() code which decides not to log anything and not to abort. -- Hallvard

Other things that might gain some speed: Unwrap the pthread wrapper to shave some time spent in critical sections: <http://folk.uio.no/hbf/OpenLDAP/unwrap-pthreads.txt> For that matter, unwrap frequently used small wrappers like ber_memalloc. A Makefile target which builds with gcc -fprofile-generate, runs some tests, then does make clean and rebuilds with -fprofile-use. Except it didn't work for me, ld complained about __gcov_merge_add. Oh well. Use the C99 'restrict' keyword when available, e.g. on struct berval* parameters. Functions that e.g. receive a struct berval*, uses it frequently, and modifies bv->bv_val[...], cannot be optimized well: Sometimes the members _could_ have been kept in registers, but the compiler cannot know that because as far as it knows bv_val may be pointing back into bv, so it must re-read bv after changing bv_val[...]. (Of course another way would be to rewrite such code to extract the bv members to a local variable, but that'd be more work per function.) Howard Chu writes: I'm fairly sure I've needed once in a while to turn on debug output to see why som slap tool failed, at least. Haven't paid attention to when it happens, I'll try to remember to report it next time it happens. I dunno. Personally I'd be happy to lose TRACE and maybe ARGS from the default, but then I haven't done anything like your amount of debugging. I find myself asking users for loglevel STATS output more often than TRACE - since people think it's a good idea to turn on full logging and then only show the last lines of the log, cut off after the relevant STATS log which might have been all that was needed. -- Hallvard

Quanah Gibson-Mount wrote: OK, that lends some weight to the idea that we have too many assert()s in the 2.4 code... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

Aaron Richton writes: Or too many Debug()s. To test which, you could make include/ac/assert.h contain just the line "#include <assert.h>", then configure with one but not both of --disable-debug and CPPFLAGS=-DNDEBUG. Well, there's assert(we kept track of what's going on) and then there's assert(we obeyed our own calling conventions to this static function). And assert(the pointer we are about to follow is not NULL), which helps explain why a crash happens but isn't usually needed to cause the crash. I'd like something like an assume() macro and an assert() macro, where assume() could be #defined as assert or noop or, if the compiler supports it, a compiler hint:-) -- Hallvard