From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 0nYSNE1Bp2OzmAgAWB0awg (envelope-from ) for ; Sat, 24 Dec 2022 13:13:33 -0500 Received: by simark.ca (Postfix, from userid 112) id C380D1E222; Sat, 24 Dec 2022 13:13:33 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=n1pXMBE1; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [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 63F4E1E110 for ; Sat, 24 Dec 2022 13:13:33 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CD2D03854178 for ; Sat, 24 Dec 2022 18:13:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CD2D03854178 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1671905612; bh=3ehnNwhlo1u6K4xBFLqPticK4ti3Cal7K72dtoza5Co=; h=Date:To:Cc:In-Reply-To:Subject:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=n1pXMBE10zJrTSQEzBtycTbQjgrpontYqFfs/4EBhxFLqwCsZ6Fq5E9VzEjO6Q/hZ NAjJuguXbbgiYO9Co+JfCTroHt6rXOoetOH6aRNsH8ffJaWfiS28y/SF57OgcjxLaU nIXSBZU8F6/Y2HELgEjO5N8EIAh1cnKTun1SC6xI= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id AB5DD3858D1E for ; Sat, 24 Dec 2022 18:13:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AB5DD3858D1E Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p991E-0006qG-O4; Sat, 24 Dec 2022 13:13:12 -0500 Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p991E-00049w-2w; Sat, 24 Dec 2022 13:13:12 -0500 Date: Sat, 24 Dec 2022 20:13:11 +0200 Message-Id: <83o7rs4qmg.fsf@gnu.org> To: Tom Tromey Cc: tom@tromey.com, gdb-patches@sourceware.org, luis.machado@arm.com In-Reply-To: <87fsd4elb2.fsf@tromey.com> (message from Tom Tromey on Sat, 24 Dec 2022 10:57:53 -0700) Subject: Re: Two observations using GDB 13 snapshot References: <83h6xugc5v.fsf@gnu.org> <58b64bf8-90b6-d080-c060-d03761501199@arm.com> <83k02neezy.fsf@gnu.org> <835ye7e9jw.fsf@gnu.org> <87h6xrks77.fsf@tromey.com> <83mt7idacj.fsf@gnu.org> <87fsd4elb2.fsf@tromey.com> 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: , From: Eli Zaretskii via Gdb-patches Reply-To: Eli Zaretskii Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > From: Tom Tromey > Cc: Tom Tromey , gdb-patches@sourceware.org, > luis.machado@arm.com > Date: Sat, 24 Dec 2022 10:57:53 -0700 > > Eli> So you are saying that the rewrite of the DWARF scanner could be the > Eli> reason for the slowness? > > No, sorry. > > -readnow should not be affected much, if at all, by the rewrite. The > new code is not used when -readnow is given. There's a case in > dwarf2_initialize_objfile that ensures this. > > -readnow is just generally much slower because it does a lot more work. > I don't know why it would have slowed down between 12 and 13, though. > > Eli> Let me know if I can provide any additional information that could be > Eli> useful in investigating this. > > Eli> Would it be useful to open a bugzilla issue? > > The best thing would be some kind of comparison of profiles between the > two versions, to try to see what caused the slowdown. However, that's a > lot of work. > > FWIW I tend not to pay much attention to -readnow. I never use it > myself and I try to dissuade others from using it as well. -readnow doesn't interest me (I never use it), except as some evidence or data point regarding the slow reading of debug info. All I'm interested in is to help you and others understand what could be the reason for slow reading of debug info at startup, so that it could be sped up at some point.