From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 16 22:51:31 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32DEA16A41F for ; Thu, 16 Mar 2006 22:51:31 +0000 (UTC) (envelope-from ahu@outpost.ds9a.nl) Received: from outpost.ds9a.nl (outpost.ds9a.nl [213.244.168.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD50543D48 for ; Thu, 16 Mar 2006 22:51:30 +0000 (GMT) (envelope-from ahu@outpost.ds9a.nl) Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 6459140E9; Thu, 16 Mar 2006 23:51:25 +0100 (CET) Resent-From: bert.hubert@netherlabs.nl Resent-Date: Thu, 16 Mar 2006 23:51:25 +0100 Resent-Message-ID: <20060316225125.GA15355@outpost.ds9a.nl> Resent-To: freebsd-hackers@freebsd.org Date: Thu, 16 Mar 2006 23:49:12 +0100 From: bert hubert To: freebsd-hackers@freebsd.org Message-ID: <20060316224912.GA14905@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: unsatisfying c++/boost::multi_index_container::erase performance on at least FreeBSD 6.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 22:51:31 -0000 Dear FreeBSD hackers, I'm working on improving the PowerDNS recursor for a big FreeBSD-loving internet provider in The Netherlands and I am hitting some snags. I also hope this is the appropriate list to share my concerns. Pruning the cache is very very slow on the providers FreeBSD 6.0 x86 systems whereas it flies on other operating systems. I've managed to boil down the problem to the code found on http://ds9a.nl/tmp/cache-test.cc which can be compiled with: 'g++ -O3 -I/usr/local/include cache-test.cc -o cache-test' after installing Boost from the ports. The problem exists both with the system compiler and with a self-compiled g++ 4.1. Here are some typical timings: $ ./cache-test Creating.. Copying 499950 nodes 100 345 usec 3.45 usec/erase 300 3298 usec 10.99 usec/erase 500 8749 usec 17.50 usec/erase 700 72702 usec 103.86 usec/erase 900 46521 usec 51.69 usec/erase On another operating system with almost the same cpu: $ ./cache-test Creating.. Copying 499950 nodes 100 62 usec 0.62 usec/erase 300 187 usec 0.62 usec/erase 500 347 usec 0.69 usec/erase 700 419 usec 0.60 usec/erase 900 575 usec 0.64 usec/erase I've toyed with MALLOC_OPTIONS, especially the >> options, I've tried GLIBCXX_FORCE_NEW, I've tried specifying a different STL allocator in the c++ code, it all doesn't change a thing. A quick gprof profile shows a tremendous number of calls to 'ifree' but that may be due to the copying of the container going on between test runs. Any help would be very appreciated as I am all out of clues. Thanks. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services