From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org 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 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=3ehnNwhlo1u6K4xBFLqPticK4ti3Cal7K72dtoza5Co=; b=EOKnyJOC47p2 ClYY8yEvLnYZNVRInNgD8/xNKwHGylWERsRPKoPykey4blapK0KzLezHHjB2R2AdxEmzk+4FJ2o8Y rhSoM+wMQGb7EC+FbOgPE74WJIrs2mDu11ACFX/VB0+fep3vOaWSIny571AfuvJJL4VIyORYkBQj4 RjJYnfTTmyB7jsHcjCDld64VSGKpmuw+Kmqtr3hbeqMMtLE3AoNDHrkFOQJQHCWsYegBjedBPyhKm eJ6yrdFXeMa8SqKzvJlEM6EbJeeDnT03v2xr8R1VwO0rMiJtLTI1bYyKw46DXIJgfu2c57crqgiXp B3gH8A9LoYahX4dGqKpDdg==; 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> From: Eli Zaretskii 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-Spam-Status: No, score=1.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > 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.