From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dov Grobgeld Newsgroups: gmane.emacs.bugs Subject: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU Date: Wed, 9 May 2012 00:07:05 +0300 Message-ID: References: <20253.9861.848886.122482@fencepost.gnu.org> <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> <877gwm3ajn.fsf@gnu.org> <83txzq1s4y.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d04446c11d68d3704bf8cc472 X-Trace: dough.gmane.org 1336511284 16508 80.91.229.3 (8 May 2012 21:08:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 8 May 2012 21:08:04 +0000 (UTC) Cc: Chong Yidong , 10580@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue May 08 23:08:03 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SRrda-0007kB-Ge for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 May 2012 23:08:02 +0200 Original-Received: from localhost ([::1]:41887 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRrdZ-0000Kj-R0 for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 May 2012 17:08:01 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48018) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRrdU-0000KY-Lh for bug-gnu-emacs@gnu.org; Tue, 08 May 2012 17:07:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SRrdS-00028e-JE for bug-gnu-emacs@gnu.org; Tue, 08 May 2012 17:07:56 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:40694) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRrdS-00028L-DI for bug-gnu-emacs@gnu.org; Tue, 08 May 2012 17:07:54 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SRrfV-0001nK-TE for bug-gnu-emacs@gnu.org; Tue, 08 May 2012 17:10:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dov Grobgeld Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 May 2012 21:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10580 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10580-submit@debbugs.gnu.org id=B10580.13365113636847 (code B ref 10580); Tue, 08 May 2012 21:10:01 +0000 Original-Received: (at 10580) by debbugs.gnu.org; 8 May 2012 21:09:23 +0000 Original-Received: from localhost ([127.0.0.1]:41728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRres-0001mO-IQ for submit@debbugs.gnu.org; Tue, 08 May 2012 17:09:23 -0400 Original-Received: from mail-ob0-f172.google.com ([209.85.214.172]:56648) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRrep-0001mC-Qb for 10580@debbugs.gnu.org; Tue, 08 May 2012 17:09:21 -0400 Original-Received: by obbeh20 with SMTP id eh20so10175683obb.3 for <10580@debbugs.gnu.org>; Tue, 08 May 2012 14:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2z2Ud76vkHhYfRx9lPhdt6LrV3zdSbkbCW+PaG7QLsg=; b=QQ3lHKCPSZU/RUdkWYbYfOuT5gxaGexwL4rPqJqMIn2v6pL0+VskvNNRUvr3pdYQJ6 cNTtXqIqbKRgy+t3LAemydxqhADCllbsYDeATten1PR2eYDbRIjL5kkel1zyJxvnnFwb +GKQV92V+B1/vpuE5WkFa7QeEDFNqjRPfjwNKCc0dg/lrWwsLoxnc6LEmlWwsMtwMov6 ocfwvfm9AKl3oe/3lWktpYIK/lNa5l3Hejv7iPceHW8gl9UHOKrAqrIHrEhw733PwDVe oVMp0IsIexS/8v1/eO3g9vfyfQ6PVkXS8h1YARirOwCgGNIg8wWwXBWUMWj16U/71gwf zXEQ== Original-Received: by 10.182.40.71 with SMTP id v7mr54404obk.5.1336511225564; Tue, 08 May 2012 14:07:05 -0700 (PDT) Original-Received: by 10.182.60.137 with HTTP; Tue, 8 May 2012 14:07:05 -0700 (PDT) In-Reply-To: <83txzq1s4y.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:59875 Archived-At: --f46d04446c11d68d3704bf8cc472 Content-Type: text/plain; charset=UTF-8 So my latest investigations suggest that the problem is the "-file-list-exec-source-files" command which generates the huge output due to the large number of files that is part of the project. The following shows the problem from the command line. echo -file-list-exec-source-files > /tmp/gdb.in gdb MyExec < /tmp/gdb.in > /tmp/gdb.out wc /tmp/gdb.out 11 69 3725105 /tmp/gdb.out (Note that this is on a my home box, where the output is much larger than what I reported this morning possibly due to different paths). So there are still several questions: * Why does it take several minutes to parse a 3.7M file? Could it be related to the fact that gdb-mi/emacs concatinates the entire string before trying to parse it. Still 3.7M is far too much. * Noted that I can't run gdb MyExec < /tmp/gdb.in in a shell buffer. It gets slower and slower while the CPU stays at 100%. * There is a huge redundancy in gdb.out. The command -file-list-exec-source-files should output all source files included, but the same source files are listed multiple times. Consider the huge file size reduction after sorting and uniq'ing: perl -ne 'while(/(\w+)=\"(.*?)\"/g) { print "$1=$2\n"; }' /tmp/gdb.out | sort | uniq | wc 3931 3931 220654 Why doesn't -file-list-exec-source file do uniq internally. This seems like a bug in gdb. * Why does gdb-mi.el do -file-list-exec-source-files at all? Can't it search for source files on demand? Regards, Dov On Tue, May 8, 2012 at 8:47 PM, Eli Zaretskii wrote: > > From: Chong Yidong > > Date: Wed, 09 May 2012 00:25:00 +0800 > > Cc: 10580@debbugs.gnu.org > > > > Those are status messages from turning on GDB's MI (machine interface) > > system, I think, though I don't see why it makes so much difference in > > your case. > > > > If you type, from the shell, > > > > gdb -i=mi YOUR-BINARY > > r > > > > do you similarly see a huge output? > > As you know, in addition to "run", gdb-mi.el sends lots of other > commands behind the scenes, so the above is not a faithful simulation > of what happens when GDB is run by Emacs. But I agree that if the > above produces similarly voluminous output, we cannot really blame > gdb-mi.el. > > --f46d04446c11d68d3704bf8cc472 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So my latest inv= estigations suggest that the problem is the "-file-list-exec-source-fi= les" command which generates the huge output due to the large number o= f files that is part of the project.

The following shows the problem from the command line.

echo -fil= e-list-exec-source-files > /tmp/gdb.in
= gdb MyExec < /tmp/gdb.in > /tmp/gdb.out=
wc /tmp/gdb.out
=C2=A0=C2=A0=C2=A0=C2=A0 11=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 69 3725105 /tmp/gdb.out

(Note that this is on a my home box, whe= re the output is much larger than what I reported this morning possibly due= to different paths).

So there are still several questions:

* Why does it take several minutes to parse a 3.7M file? Could it be re= lated to the fact that gdb-mi/emacs concatinates the entire string before t= rying to parse it. Still 3.7M is far too much.

* Noted that I can= 9;t run gdb MyExec < /tmp/gdb.in in a shel= l buffer. It gets slower and slower while the CPU stays at 100%.

* There is a huge redundancy in gdb.out. The command -file-list-exec-so= urce-files should output all source files included, but the same source fil= es are listed multiple times. Consider the huge file size reduction after s= orting and uniq'ing:

perl -ne 'while(/(\w+)=3D\"(.*?)\"/g) { print "$1=3D= $2\n"; }' /tmp/gdb.out | sort | uniq | wc

=C2=A0=C2= =A0 3931=C2=A0=C2=A0=C2=A0 3931=C2=A0 220654

Why doesn't -file-l= ist-exec-source file do uniq internally. This seems like a bug in gdb.

* Why does gdb-mi.el do -file= -list-exec-source-files at all? Can't it search for source files on dem= and?

Regards,
Dov

On Tue= , May 8, 2012 at 8:47 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Chong Yidong <cyd@gnu.org>
> Date: Wed, 09 May 2012 00:25:00 +0800
> Cc: 10580@debbugs.gnu.org=
>
> Those are status messages from turning on GDB's MI (machine interf= ace)
> system, I think, though I don't see why it makes so much differenc= e in
> your case.
>
> If you type, from the shell,
>
> =C2=A0 gdb -i=3Dmi YOUR-BINARY
> =C2=A0 r
>
> do you similarly see a huge output?

As you know, in addition to "run", gdb-mi.el sends lots of = other
commands behind the scenes, so the above is not a faithful simulation
of what happens when GDB is run by Emacs. =C2=A0But I agree that if the
above produces similarly voluminous output, we cannot really blame
gdb-mi.el.


--f46d04446c11d68d3704bf8cc472--