From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19814 invoked by alias); 20 Jul 2012 10:02:46 -0000 Received: (qmail 19804 invoked by uid 22791); 20 Jul 2012 10:02:44 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,SPF_FAIL,TW_BJ,TW_CP X-Spam-Check-By: sourceware.org Received: from gbenson.demon.co.uk (HELO gbenson.demon.co.uk) (80.177.220.214) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 Jul 2012 10:02:25 +0000 Date: Fri, 20 Jul 2012 10:02:00 -0000 From: Gary Benson To: =?iso-8859-1?Q?Andr=E9_P=F6nitz?= Cc: gdb-patches@sourceware.org Subject: Re: [RFA 5/4 take 2] Improved linker-debugger interface Message-ID: <20120720100222.GC3153@redhat.com> Mail-Followup-To: =?iso-8859-1?Q?Andr=E9_P=F6nitz?= , gdb-patches@sourceware.org References: <20120719151913.GF25093@redhat.com> <20120719211740.GB2947@klara.mpi.htwm.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="eJnRUKwClWJh1Khz" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120719211740.GB2947@klara.mpi.htwm.de> 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: 2012-07/txt/msg00387.txt.bz2 --eJnRUKwClWJh1Khz Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-length: 1442 André Pönitz wrote: > On Thu, Jul 19, 2012 at 04:19:13PM +0100, Gary Benson wrote: > > Attached is a patch to avoid calling update_section_map from the > > probes interface. Updated timings are as follows: > > > > no of solibs 100 250 500 1000 2000 5000 > > ------------------------------------------------------------ > > old interface 1 3 9 35 141 942 > > new interface 0 0 1 4 14 89 > > (times in seconds) > > > > So, with this patch GDB is not three but ten times faster. > > It pretty much looks like there is still some quadratic behaviour > somewhere... Yes. It's difficult to avoid given the current architecture. target_so_ops->current_sos() is expected to return a freshly allocated list of libraries to update_solib_list(), and the latter is expected to free them. This makes sense for the standard interface, which reads everything from the inferior into a list and returns it. The probes interface already has everything read by the time target_so_ops->current_sos() is called, but it can't just return its own copy because the rest of GDB will start freeing bits of it, so it needs to copy it. Every time a library is loaded, a new copy of the list is made, but every time a library is loaded the list is one element bigger. You can see all the memcpy calls in the profile I attached. Cheers, Gary -- http://gbenson.net/ --eJnRUKwClWJh1Khz Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=profile Content-length: 1334 samples % image name symbol name ------------------------------------------------------------------------- 347937 11.4258 no-vmlinux /no-vmlinux 317639 10.4309 libc-2.13.so __memcpy_sse2 231494 7.6020 gdb lookup_minimal_symbol_text 230405 7.5662 gdb objfile_data 206993 6.7974 libc-2.13.so __GI_memset 169853 5.5778 gdb svr4_same 154056 5.0590 gdb lookup_minimal_symbol 105589 3.4674 libc-2.13.so _int_free 99916 3.2811 gdb solib_add 93557 3.0723 libc-2.13.so _int_malloc 78125 2.5655 gdb namespace_update_incremental 74170 2.4357 gdb create_longjmp_master_breakpoint 70165 2.3041 libc-2.13.so __strcmp_sse2 62896 2.0654 gdb lookup_minimal_symbol_and_objfile 55876 1.8349 gdb create_overlay_event_breakpoint 51030 1.6758 gdb get_objfile_arch 46512 1.5274 gdb create_exception_master_breakpoint 45851 1.5057 gdb create_std_terminate_master_breakpoint 40766 1.3387 ld-2.16.90.so _dl_name_match_p 40233 1.3212 gdb allocate_objfile 34723 1.1403 ld-2.16.90.so _dl_map_object_from_fd 33676 1.1059 libc-2.13.so freehook 31009 1.0183 ld-2.16.90.so _dl_map_object --eJnRUKwClWJh1Khz--