From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14090 invoked by alias); 6 Dec 2001 21:38:56 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 14029 invoked from network); 6 Dec 2001 21:38:54 -0000 Received: from unknown (HELO localhost.cygnus.com) (216.138.202.10) by sources.redhat.com with SMTP; 6 Dec 2001 21:38:54 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id EB7423D5E for ; Thu, 6 Dec 2001 16:38:50 -0500 (EST) Message-ID: <3C0FE56A.6070203@cygnus.com> Date: Thu, 06 Dec 2001 13:38:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.3) Gecko/20011020 X-Accept-Language: en-us MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: [Fwd: gdb "call" very slow on large C++ program; 2 possible patches] Content-Type: multipart/mixed; boundary="------------040300010407060106050003" X-SW-Source: 2001-12/txt/msg00067.txt.bz2 This is a multi-part message in MIME format. --------------040300010407060106050003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 35 This might be interesting. Andrew --------------040300010407060106050003 Content-Type: message/rfc822; name="gdb "call" very slow on large C++ program; 2 possible patches" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gdb "call" very slow on large C++ program; 2 possible patches" Content-length: 7876 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: ac131313@localhost.cygnus.com Received: from localhost (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id 062863C81 for ; Sat, 17 Nov 2001 22:18:16 -0500 (EST) Received: from pop.cygnus.com by localhost with IMAP (fetchmail-5.8.8) for ac131313@localhost (single-drop); Sat, 17 Nov 2001 22:18:16 -0500 (EST) Received: from fencepost.gnu.org (fencepost.gnu.org [199.232.76.164]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id TAA24905; Sat, 17 Nov 2001 19:15:44 -0800 (PST) Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.22 #1 (Debian)) id 165IQF-0003N3-00; Sat, 17 Nov 2001 22:15:07 -0500 Received: from [216.191.234.70] (helo=Mitel.COM) by fencepost.gnu.org with smtp (Exim 3.22 #1 (Debian)) id 165IPq-0003If-00 for ; Sat, 17 Nov 2001 22:14:42 -0500 Received: from Software.Mitel.COM (software [134.199.30.49]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id WAA25841 for ; Sat, 17 Nov 2001 22:14:30 -0500 (EST) Received: from sharmanpc.software.mitel.com ([134.199.112.30]) by Software.Mitel.COM (V8/MAIL-HUB-2.0) with ESMTP id WAA23467 for ; Sat, 17 Nov 2001 22:14:29 -0500 (EST) Received: (from sharman@localhost) by sharmanpc.software.mitel.com (8.11.6/8.11.6) id fAI3ESR18678; Sat, 17 Nov 2001 22:14:28 -0500 From: Richard Sharman Message-ID: <15351.10132.782759.852559@sharmanpc.software.mitel.com> To: bug-gdb@gnu.org Cc: sharman@sharmanpc.software.Mitel.COM Subject: gdb "call" very slow on large C++ program; 2 possible patches X-Mailer: VM 6.92 under Emacs 21.1.1 Sender: bug-gdb-admin@gnu.org Errors-To: bug-gdb-admin@gnu.org X-BeenThere: bug-gdb@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Bug reports for GDB, the GNU debugger List-Unsubscribe: , List-Archive: Date: Sat, 17 Nov 2001 22:14:28 -0500 Content-Type: text Content-length: 5473 We have a largish C++ program, and when we use the gdb "call" function it takes about 12 seconds for GDB to perform the operation. (The function itself is very quick. In the previous C version of the program the call was virtually instantaneous.) I have two patches. The first patch reduced the time to about 5 seconds for the first call but 2 seconds for the second call; the second patch reduced to time to about an eigth of a second. The first patch was to "overload_list_add_symbol" in symtab.c . This function was taking a lot of time demangling symbols that didn't match. The patch did two things: * See if the name to search for matched the beginning of the mangled name. If it did not, then exit immediately. This saved the call to cplus_demangle and the xmalloc and free calls. * Set the "readin" flag after the two for loops in the ALL_PSYMTABS loop. This catches the cases of files that have no symbols and thus never get the readin flag set. (This may seem trivial but happened in 4860 files in our program so was quite significant.) As mentioned above, this helped signficantly, especially on the second call. However, there was still a noticable delay before the called function was executed. We noticed that the gdb "info func" on the command name was executed immediately, and wondered why it didn't have the same delay in finding the function name. We found it was not using the "make_symbol_overload_list" function, but instead calling "search_symbols". The second patch was then to "find_overload_match" in valops.c, to use the "search_symbols" function. Both patches work for us but I am not at all familiar with the workings of gdb so do not know how reliable they are. I have no idea why there appear to be two functions doing essentially the same thing but one takes 12 seconds and one takes 0.125 seconds. The second patch makes the first patch unncessary since make_symbol_overload_list is not called other than in the original valops.c. Here are the two patches. They are agains the cvs source as of 14 November checked out using cvs -z9 -d :pserver:anoncvs@sources.redhat.com:/cvs/src co -r \ gdb_5_0-2000-04-10-branch gdb+dejagnu -------------------- Patch 1 -------------------- *** symtab.c.orig Mon Apr 3 22:08:52 2000 --- symtab.c Wed Nov 14 23:23:13 2001 *************** *** 4460,4468 **** { int newsize; int i; /* Get the demangled name without parameters */ ! char *sym_name = cplus_demangle (SYMBOL_NAME (sym), DMGL_ARM | DMGL_ANSI); if (!sym_name) { sym_name = (char *) xmalloc (strlen (SYMBOL_NAME (sym)) + 1); --- 4460,4476 ---- { int newsize; int i; + char *sym_name; + + + /* skip symbols that cannot match */ + if (strncmp(SYMBOL_NAME (sym), oload_name, strlen(oload_name)) != 0) + { + return; + } /* Get the demangled name without parameters */ ! sym_name = cplus_demangle (SYMBOL_NAME (sym), DMGL_ARM | DMGL_ANSI); if (!sym_name) { sym_name = (char *) xmalloc (strlen (SYMBOL_NAME (sym)) + 1); *************** *** 4567,4574 **** --- 4575,4590 ---- /* This will cause the symbol table to be read if it has not yet been */ s = PSYMTAB_TO_SYMTAB (ps); } + + /* If no symbols were found, mark it as read anyway so that + we skip it next time. */ + if (ps && !ps->readin) + { + ps->readin = 1; + } } + /* Search upwards from currently selected frame (so that we can complete on local vars. */ ------------------------------------------------- -------------------- Patch -------------------- *** valops.c.orig Sun Apr 9 09:02:10 2000 --- valops.c Thu Nov 15 15:25:36 2001 *************** *** 2739,2744 **** --- 2739,2747 ---- int boffset; register int jj; register int ix; + struct symbol_search *symbols; + struct symbol_search *p; + struct cleanup *old_chain; char *obj_type_name = NULL; char *func_name = NULL; *************** *** 2799,2807 **** return 0; } ! oload_syms = make_symbol_overload_list (fsym); ! while (oload_syms[++i]) ! num_fns++; if (!num_fns) error ("Couldn't find function %s", func_name); } --- 2802,2821 ---- return 0; } ! search_symbols (SYMBOL_NAME (fsym), FUNCTIONS_NAMESPACE, 0, (char **) NULL, &symbols); ! old_chain = make_cleanup ((make_cleanup_func) free_search_symbols, symbols); ! for (p = symbols; p != NULL; p = p->next) ! { ! num_fns++; ! } ! oload_syms = (struct symbol **) xmalloc ((num_fns + 1) * sizeof (struct symbol *)); ! i = -1; ! for (p = symbols; p != NULL; p = p->next) ! { ! oload_syms[++i] = p->symbol; ! } ! do_cleanups (old_chain); ! if (!num_fns) error ("Couldn't find function %s", func_name); } *************** *** 2946,2952 **** *symp = oload_syms[oload_champ]; free (func_name); } ! return oload_incompatible ? 100 : (oload_non_standard ? 10 : 0); } --- 2960,2966 ---- *symp = oload_syms[oload_champ]; free (func_name); } ! free(oload_syms); return oload_incompatible ? 100 : (oload_non_standard ? 10 : 0); } ------------------------------------------------- Richard Sharman _______________________________________________ Bug-gdb mailing list Bug-gdb@gnu.org http://mail.gnu.org/mailman/listinfo/bug-gdb --------------040300010407060106050003--