From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32711 invoked by alias); 9 Mar 2010 18:40:59 -0000 Received: (qmail 32648 invoked by uid 48); 9 Mar 2010 18:40:42 -0000 Date: Tue, 09 Mar 2010 18:40:00 -0000 Message-ID: <20100309184042.32647.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/41975] [C++0x] [DR579] unordered_set::erase performs worse when nearly empty In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jzwinck at gmail dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-03/txt/msg00827.txt.bz2 ------- Comment #17 from jzwinck at gmail dot com 2010-03-09 18:40 ------- (In reply to comment #16) > there is evidence (eg, the Dinkumware implementation) that returning an > iterator doesn't necessarily impact performance. The GCC implementation does have poor performance. Why not leave the (performance-improving) patch in place until someone actually comes up with an implementation for GCC which does perform well? As it stands, users are left in a strange situation, being told that the performance (in GCC) is poor, but that it has to be this way because of Dinkumware (which, it's claimed, is fast). Doesn't this only serve to drive users away from GCC's implementation? To be clear, I am very much in favor of any solution which provides approximately optimal performance. Boost, for example, chose to implement a new method called "erase_return_void" for users who care about performance of this operation--a workaround, but with emphasis on "work." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41975