From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id afcoHcDcsl9CagAAWB0awg (envelope-from ) for ; Mon, 16 Nov 2020 15:10:40 -0500 Received: by simark.ca (Postfix, from userid 112) id 6F27E1F08B; Mon, 16 Nov 2020 15:10:40 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=MAILING_LIST_MULTI,RDNS_NONE autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 276371E58F for ; Mon, 16 Nov 2020 15:10:40 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BE3CC3851C1D; Mon, 16 Nov 2020 20:10:39 +0000 (GMT) Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 4DC903851C1D for ; Mon, 16 Nov 2020 20:10:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4DC903851C1D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [172.16.0.95] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id B6E6E1E58F; Mon, 16 Nov 2020 15:10:36 -0500 (EST) Subject: Re: [RFA 1/6] change gmp_string_asprintf to return an std::string To: Joel Brobecker References: <1604817017-25807-1-git-send-email-brobecker@adacore.com> <1605430184-81335-1-git-send-email-brobecker@adacore.com> <1605430184-81335-2-git-send-email-brobecker@adacore.com> <3e16e18e-e5bc-7d6a-1404-19c7d22cda6e@simark.ca> <20201116035501.GB609903@adacore.com> From: Simon Marchi Message-ID: <88b17c69-bf6c-f98f-059b-6b1bf2b03408@simark.ca> Date: Mon, 16 Nov 2020 15:10:36 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201116035501.GB609903@adacore.com> Content-Type: text/plain; charset=utf-8 Content-Language: tl Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2020-11-15 10:55 p.m., Joel Brobecker wrote: > I don't know if that's really important in the context of this function > which I don't think will be called often, but your suggestion raises > a question: Which option should we favor? Allocating a memory region > twice, or formatting twice... I think that memory allocation is in general heavier than the formatting part. In the best case, allocation can be very quick, but in the worst case it can be quite costly, I guess that depends on the allocator. Allocating could involve some locking or some syscall. Simon