From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: rusi Newsgroups: gmane.emacs.help Subject: Re: Emacs launches excruciatingly slowly Date: Thu, 3 Nov 2011 06:23:41 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <2226EBAC-5427-4190-AF4E-F9E21DFEB725@ryanwersal.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1332968005 9369 80.91.229.3 (28 Mar 2012 20:53:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 28 Mar 2012 20:53:25 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Mar 28 22:53:25 2012 Return-path: Envelope-to: geh-help-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 1SCzrw-0000cL-Uf for geh-help-gnu-emacs@m.gmane.org; Wed, 28 Mar 2012 22:53:25 +0200 Original-Received: from localhost ([::1]:52679 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCzrw-0000Af-AI for geh-help-gnu-emacs@m.gmane.org; Wed, 28 Mar 2012 16:53:24 -0400 Original-Path: usenet.stanford.edu!postnews.google.com!c16g2000pre.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 45 Original-NNTP-Posting-Host: 116.74.138.11 Original-X-Trace: posting.google.com 1320326721 12496 127.0.0.1 (3 Nov 2011 13:25:21 GMT) Original-X-Complaints-To: groups-abuse@google.com Original-NNTP-Posting-Date: Thu, 3 Nov 2011 13:25:21 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: c16g2000pre.googlegroups.com; posting-host=116.74.138.11; posting-account=mBpa7woAAAAGLEWUUKpmbxm-Quu5D8ui User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: HUALESNKRC X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110920 Firefox/3.6.23,gzip(gfe) Original-Xref: usenet.stanford.edu gnu.emacs.help:189615 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:84172 Archived-At: On Nov 3, 10:43=A0am, Eli Zaretskii wrote: > > From: Ryan Wersal > > Date: Wed, 2 Nov 2011 14:34:40 -0500 > > Cc: "" > > > I can confirm that all network drives are functioning correctly. Just t= o be thorough, I also removed all network drives. The problem continues to = persist. > > Can you use some OS-monitoring tool, like Process Monitor, to see just > what Emacs is doing during those long minutes? > > If you can install GDB (you can find one on the MinGW site), then > starting GDB like this: > > =A0gdb -p EMACS_PID > > where EMACS_PID is the Emacs process ID (a number shown, e.g., by the > Task Manager), and then, once GDB is up and shows its "(gdb)" prompt, > typing this command: > > =A0(gdb) thread apply all bt > > will show where each one of the Emacs threads is wasting the time. > > Doing that procedure several times during the wait should reveal where > this time is spent. =A0(After each "thread apply" command, type "q" to > exit the debugger and let Emacs run some more, then repeat the above > recipe.) > > (It sounds like this kind of issue should be discussed not here, but > rather on emacs-de...@gnu.org, or as part of a bug report sent with > "M-x report-emacs-bug RET" so please follow up there.) I remember emacs hanging (well maybe I should say 'hanging' because I did not wait 43 minutes :-). This must have been about 9-10 years ago, linux box on internal network when something was wrong with the network. Dont remember exactly what wrong... Doing something to the effect of 'networking off' (again dont remember the details) made emacs startup normal (2-3 seconds). Unplugging the network cord without doing the corresponding command worsens/causes the problem