From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 09803384607A for ; Tue, 1 Sep 2020 13:26:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 09803384607A Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-159-W0sFBiJLMYyQ8RLbTtXcAQ-1; Tue, 01 Sep 2020 09:26:00 -0400 X-MC-Unique: W0sFBiJLMYyQ8RLbTtXcAQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9FFD31019625; Tue, 1 Sep 2020 13:25:59 +0000 (UTC) Received: from localhost (unknown [10.33.36.9]) by smtp.corp.redhat.com (Postfix) with ESMTP id 289915D9CC; Tue, 1 Sep 2020 13:25:59 +0000 (UTC) Date: Tue, 1 Sep 2020 14:25:58 +0100 From: Jonathan Wakely To: =?iso-8859-1?Q?Fran=E7ois?= Dumont Cc: "libstdc++@gcc.gnu.org" , gcc-patches Subject: Re: Deque rotate on current node Message-ID: <20200901132558.GI3400@redhat.com> References: <2a947ca5-56ea-cd46-f4bb-c094fa980745@gmail.com> <20200117100152.GV60955@redhat.com> <4e1d5fbf-9c10-8cfa-f71f-66d8936a6ef5@gmail.com> <72fc2aae-1c9b-f862-7370-3d94c87fa0e1@gmail.com> <00179247-4301-d138-c72c-6a952e4b662b@gmail.com> MIME-Version: 1.0 In-Reply-To: <00179247-4301-d138-c72c-6a952e4b662b@gmail.com> X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0.002 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Spam-Status: No, score=-8.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 13:26:04 -0000 On 01/09/20 14:06 +0200, François Dumont wrote: >Hi > >No chance to review this small patch ? I did review it, and I wasn't convinced it was a good change. It only helps a particular usage pattern, and might hurt in other cases. I don't agree with your assertion that you use std::deque when you only use push_front() and you use std::list if you need both push_front() and push_back(). Ideally we'd keep the most recently reallocated node around for reuse, and then in the situation you describe the first push_front would allocate a new node, but if you immediately do pop_back() we wouldn't deallocate the node. But I haven't figured out a way to do that caching without an ABI break. The patch also has no tests. Are our existing tests sufficient to cover this case? Do we want a test that verifies that we don't allocate a new node if doing push_front() into an empty deque? I would like to see a test doing something like: std::deque> d; const int count = CustomAlloc::number_of_allocations; d.push_front(1); VERIFY( CustomAlloc::number_of_allocations == count ); d.pop_front(); d.push_back(1); VERIFY( CustomAlloc::number_of_allocations == count );