From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id hdBgBZpBz2eXUwsAWB0awg (envelope-from ) for ; Mon, 10 Mar 2025 15:46:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1741635993; bh=GwbJftrYpIi+diYNbQqrPDZJz9lymBGhO+bjY1NH8DI=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=MBwHB+1704Vk+sI+3rDEwQZEhIjTIAy25QpxpgHEaar8mssgO6fuwPtTHPRVlP2Cb BkOm3hOqSMv6zWmkfmXNDYuBvjsauiA7yc2umYBCOs8HFnM3Yu7DlvyVE86MEe//As D4diNkXgPXtOCTClRTFZ8SdeGGEhVAD65S79glWA= Received: by simark.ca (Postfix, from userid 112) id EB0BE1E105; Mon, 10 Mar 2025 15:46:33 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=unavailable autolearn_force=no version=4.0.0 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=BvwMPx31; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=Q0WJ+KJ4; dkim-atps=neutral Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 980501E05C for ; Mon, 10 Mar 2025 15:46:33 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 317833858C2C for ; Mon, 10 Mar 2025 19:46:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 317833858C2C Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=BvwMPx31; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=Q0WJ+KJ4 Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id C4B663858D20 for ; Mon, 10 Mar 2025 19:45:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C4B663858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C4B663858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741635958; cv=none; b=UCXVH7cIoXLFmWtgJWGZuIPzNRwzLQk/aU/idylGk3EbdEpEbFxDUS1uCxPlv2yv55+0G1XlBpoERbLgNXHMpy9RdjJlG7uxWE3OiHOzDOnKjksK1HOo+ITW3OAtD1xnQ51iCpRk34I6rgRl6CXUZCLzzX7qP7HcMGFEcr9k4eQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741635958; c=relaxed/simple; bh=GwbJftrYpIi+diYNbQqrPDZJz9lymBGhO+bjY1NH8DI=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=CzxxOytll4+WX9TV6AJGuuc4T41t77vsVi9prC2gtVpeQWMXDKOh7jPWMAD2nDS2TU6Ur2i4qS0KZDH2VWds27WhnVR/ouPg41qxoKdR6A2xSN1VJy2XRXb7M3ocRHvLDfPI0idf22GWCYP6UFms5+vxYdqcqlexziuhVGyDD3A= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C4B663858D20 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1741635958; bh=GwbJftrYpIi+diYNbQqrPDZJz9lymBGhO+bjY1NH8DI=; h=Date:Subject:To:References:From:In-Reply-To:From; b=BvwMPx31kPmBSno5GRvQpWfNirqfjXyoUpaiLX/xmidPlgxT+YLE8lWQ2MD/7r4t2 F4fcsgO9sUdAtvnukl5bDT6GpSA3vSP8cyv+2CQk4yu40V2x5Vbrr7TKOz+OIpI4nZ VmeDIWLxKSud0jk/p9UHJP2gOD+jkYNOxDQINrZQ= Received: by simark.ca (Postfix, from userid 112) id 730771E10A; Mon, 10 Mar 2025 15:45:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1741635957; bh=GwbJftrYpIi+diYNbQqrPDZJz9lymBGhO+bjY1NH8DI=; h=Date:Subject:To:References:From:In-Reply-To:From; b=Q0WJ+KJ45R+bypCCfbeUnQ0A3v3zWx8Tnqkb6+aY6aQpixz+6KxxIDU8ott6q7GPe MKroagEofN6WkqEgV7kHIcyOcL/KVIO9ITmCjIfnqWfnyhV9UCToiq4lNi1wCgq3W0 KtH2ifuKUdpMm4p4Oq+dHRB9Oi3NPa6acCuvuxmo= Received: from [10.0.0.170] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 521421E05C; Mon, 10 Mar 2025 15:45:57 -0400 (EDT) Message-ID: <8c3b216e-5c62-42ce-8983-ef8e5df29bd5@simark.ca> Date: Mon, 10 Mar 2025 15:45:56 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] Add string cache and use it in cooked index To: Tom Tromey , gdb-patches@sourceware.org References: <20250310193815.2425344-1-tom@tromey.com> Content-Language: fr From: Simon Marchi In-Reply-To: <20250310193815.2425344-1-tom@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 3/10/25 3:38 PM, Tom Tromey wrote: > The cooked index needs to allocate names in some cases -- when > canonicalizing or when synthesizing Ada package names. This process > currently uses a vector of unique_ptrs to manage the memory. > > Another series I'm writing adds another spot where this allocation > must be done, and examining the result showed that certain names were > allocated multiple times. > > To clean this up, this patch introduces a string cache object and > changes the cooked indexer to use it. I considered using bcache here, > but bcache doesn't work as nicely with string_view -- because bcache > is fundamentally memory-based, a temporary copy of the contents must > be made to ensure that bcache can see the trailing \0. Furthermore, > writing a custom class lets us avoid another copy when canonicalizing > C++ names. Thanks, LGTM. Approved-By: Simon Marchi I was thinking that maybe this woud actually be a good use case for an obstack, since free'ing would probably be faster than freeing the strings individually. But we have cases where the caller passes a unique_xmalloc_ptr, in two cases we'd need an extra copy into the obstack. Simon