From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61889 invoked by alias); 19 Jun 2017 12:13:09 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 61076 invoked by uid 89); 19 Jun 2017 12:13:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Jun 2017 12:13:07 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E161D80460; Mon, 19 Jun 2017 12:13:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E161D80460 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=palves@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E161D80460 Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id AE02586D58; Mon, 19 Jun 2017 12:13:07 +0000 (UTC) Subject: Re: [PATCH v5] C++ify gdb/common/environ.c To: Simon Marchi , Sergio Durigan Junior References: <20170413040455.23996-1-sergiodj@redhat.com> <20170616222315.12779-1-sergiodj@redhat.com> <4e43c71a2ac4aa229bb262e18dec668c@polymtl.ca> Cc: GDB Patches From: Pedro Alves Message-ID: <631a235c-1f70-4435-3a97-d98b2c385f04@redhat.com> Date: Mon, 19 Jun 2017 12:13:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <4e43c71a2ac4aa229bb262e18dec668c@polymtl.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-06/txt/msg00506.txt.bz2 On 06/17/2017 09:54 AM, Simon Marchi wrote: > I actually preferred the option of adding the NULL element to the vector > in the gdb_environ constructor, since it allows always having the vector > in a consistent state. I don't think that avoiding that heap allocation > is worth the complexity it adds to the code (unless we can prove > otherwise by memory usage profiling). I'm not exactly sure what complexity this is, but I'm not going to strongly object to always putting in the NULL element, since that's what we currently do today. This shows we're missing unit test coverage at least. I was going to write something longish about premature pessimization, and on how that in my experience is really a mindset that ends up causing us to leave a bunch of easy optimizations that all adding up, do matter significantly, coming from actually running perf against gdb and seeing the sometimes quite silly hot spots that could have been easily avoided. However, I found this article, and I find that it mirrors perfectly my view, and is much better written than what I was going to say: http://www.bornsleepy.com/2014/10/27/premature-pessimization-and-the-like.html I fully subscribe to the above. Thanks, Pedro Alves