From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1945 invoked by alias); 14 May 2009 17:45:46 -0000 Received: (qmail 1931 invoked by uid 22791); 14 May 2009 17:45:44 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 14 May 2009 17:45:37 +0000 Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id n4EHjWT8032472 for ; Thu, 14 May 2009 18:45:33 +0100 Received: from qw-out-1920.google.com (qwj9.prod.google.com [10.241.195.73]) by zps37.corp.google.com with ESMTP id n4EHjULD030126 for ; Thu, 14 May 2009 10:45:31 -0700 Received: by qw-out-1920.google.com with SMTP id 9so1085993qwj.54 for ; Thu, 14 May 2009 10:45:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.81.136 with SMTP id x8mr1681212qck.95.1242323127309; Thu, 14 May 2009 10:45:27 -0700 (PDT) In-Reply-To: <20090514081402.GF7292@adacore.com> References: <8ac60eac0905051749p3b5d14d9q8903b9de8e18137f@mail.gmail.com> <20090512082530.GD7584@adacore.com> <8ac60eac0905121353i4aae7110sebb34bec1de0d6d8@mail.gmail.com> <20090513092709.GB7292@adacore.com> <8ac60eac0905131111v7a73a628o5e6dfee5969119d3@mail.gmail.com> <20090514081402.GF7292@adacore.com> Date: Thu, 14 May 2009 17:45:00 -0000 Message-ID: <8ac60eac0905141045q93bfc3fo2b22981f3b1d4db1@mail.gmail.com> Subject: Re: [patch] Eliminate quadratic slow-down on number of solibs (part 2). From: Paul Pluzhnikov To: Joel Brobecker Cc: gdb-patches@sourceware.org, Tom Tromey Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes 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 X-SW-Source: 2009-05/txt/msg00305.txt.bz2 On Thu, May 14, 2009 at 1:14 AM, Joel Brobecker wro= te: >> 3. The "don't reset all breakpoints over and over when adding >> =A0 =A0multiple solibs" patch here: > I completely misunderstood this change you proposed! I see now what > you are doing. This wouldn't help on systems such as Windows where > DLLs are "discovered" through special events while waiting for inferior > events. So shared libraries are never loaded at once, neither during > startup or attaching. Right. So Windows behaves as a program that dlopen()s all of its DLLs in sequence. >=A0But on GNU/Linux, however, you're right, there > is something to do in that case. > > I'd like to think about it, for a while... I wonder if we could use > an observer to notify clients that symbols have been loaded, rather > than calling breakpoint_re_set directly. This (I think) would effectively achieve the same result as patch#2, calling breakpoint_re_set only for individual solib. [BTW, is it ok to commit patch#2 ?] The problem is that breakpoint_re_set does a bunch of unnecessary work, even when it knows which solib it should be dealing with. In particular, for each breakpoint, it re-parses its addr_string, selects correct address (possibly skipping function prolog, etc.). When 'break main' is in effect, this one breakpoint's addr_string is parsed N times, main is looked up N times, main's prolog is skipped N times, etc. etc. This isn't quadratic, but accounts for ~15% of startup time, and adds up to minutes or large N. I see that my comment about patch#3 transforming O(N*N) into O(N) is correct only if patches #1 and #2 aren't applied. If they are applied, then (I believe) patch#3 transforms O(N*M) into O(M), where N is the number of solibs added "at once" and M is the number of current breakpoints. Thanks, --=20 Paul Pluzhnikov