From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Austin Bingham Newsgroups: gmane.emacs.devel Subject: Re: Help understanding some bad emacs behavior Date: Mon, 17 Nov 2014 15:58:18 +0000 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c2641425dfa50508100c0d X-Trace: ger.gmane.org 1416239918 15706 80.91.229.3 (17 Nov 2014 15:58:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Nov 2014 15:58:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 17 16:58:31 2014 Return-path: Envelope-to: ged-emacs-devel@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 1XqOhC-0006Ma-Jb for ged-emacs-devel@m.gmane.org; Mon, 17 Nov 2014 16:58:30 +0100 Original-Received: from localhost ([::1]:48585 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqOhC-0002MO-9i for ged-emacs-devel@m.gmane.org; Mon, 17 Nov 2014 10:58:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42615) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqOh6-0002IH-7c for emacs-devel@gnu.org; Mon, 17 Nov 2014 10:58:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XqOh4-00056d-54 for emacs-devel@gnu.org; Mon, 17 Nov 2014 10:58:24 -0500 Original-Received: from mail-la0-x22d.google.com ([2a00:1450:4010:c03::22d]:56619) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqOh3-00055H-QA for emacs-devel@gnu.org; Mon, 17 Nov 2014 10:58:22 -0500 Original-Received: by mail-la0-f45.google.com with SMTP id gm9so1849061lab.4 for ; Mon, 17 Nov 2014 07:58:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=ZEFKyvAEeC1fB0sLix8ctzkHhANkd43zxs3bazUJMdk=; b=st2uaZSoNjZMoSYv0AccjGgldkJUXrtmufR7hRtrKqGBD5qZMUwnhMfWtMrxvfJlkz l5XWp4JwwJdHVZ117y9nr8gvx+hjOJwybEL4FujTk5ixLS5RJ0fh1P9hscLB+mLYYW4G Zc2Jh3vgFEAA5nmrHquGkEah0f/84GXD/T/271dvV62ovU7UBeFZgeEB9BV9WForOJuv gUsLPaQqp90UkW8TxQLiOvbgOvQ0UNEZ2cOQ53IZWSnGoZVJPC9ahMaimmrVcxOcPnoG jl6865dQWv+tcdXpps4BOekW4B35ecuRElzZh2Hv+7fKc9bR1U32UtZ8bT4rxRszXjZu lqQg== X-Received: by 10.112.173.39 with SMTP id bh7mr29086464lbc.53.1416239899858; Mon, 17 Nov 2014 07:58:19 -0800 (PST) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::22d X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:177429 Archived-At: --001a11c2641425dfa50508100c0d Content-Type: text/plain; charset=UTF-8 Thanks for the guidance. The profiler definitely cleared things up. The pretty-print function was getting a really large structure, and all of the time was being spent in calculating indentation. Thanks again. Austin On Sun Nov 16 2014 at 8:10:15 PM Stefan Monnier wrote: > > Sorry, good point. The emacs process maxes out one of my cores for a few > > minutes. During this time emacs seems unresponsive to input, though it > does > > redraw on the screen. > > You can try M-x profiler-start RET RET before and M-x profiler-report > RET afterwards, which should tell you where time was spent. > > > Maybe the deep-seeming stack of Ffuncall/exec_byte_code/etc. is normal, > but > > it was remarkable enough to me that I thought I'd mention it. > > Yes, it's perfectly normal. If you think of how an interpreter works, > the C-level backtrace will typically look like a (deep) nesting of calls > between functions called "eval" or "apply" or "call". > > > What's the best way to get that? Bear in mind that, as far as I can tell, > > emacs isn't responding to input when I see this problem. And since I > don't > > really know where this is happening in elisp-land, I'm not sure where to > > add instrumentation or anything like that. > > You can try (setq debug-on-quit t) and hitting C-g. > If that doesn't work, do a "kill -USR2 " which should also > drop you into the debugger. > > > Stefan > --001a11c2641425dfa50508100c0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the guidance. The profiler definitely cleared things up. The pre= tty-print function was getting a really large structure, and all of the tim= e was being spent in calculating indentation. Thanks again.

<= div>Austin

On Sun Nov 16 2014 at 8:10:15 = PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> Sorry, good point.=C2=A0 The emacs process maxes out one of my= cores for a few
> minutes.=C2=A0 During this time emacs seems unresponsive to input, tho= ugh it does
> redraw on the screen.

You can try M-x profiler-start RET RET before and M-x profiler-report
RET afterwards, which should tell you where time was spent.

> Maybe the deep-seeming stack of Ffuncall/exec_byte_code/etc. is normal= , but
>=C2=A0 it was remarkable enough to me that I thought I'd mention it= .

Yes, it's perfectly normal.=C2=A0 If you think of how an interpreter wo= rks,
the C-level backtrace will typically look like a (deep) nesting of calls between functions called "eval" or "apply" or "cal= l".

> What's the best way to get that? Bear in mind that, as far as I ca= n tell,
> emacs isn't responding to input when I see this problem. And since= I don't
> really know where this is happening in elisp-land, I'm not sure wh= ere to
> add instrumentation or anything like that.

You can try (setq debug-on-quit t) and hitting C-g.
If that doesn't work, do a "kill -USR2 <emacspid>" whic= h should also
drop you into the debugger.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan
--001a11c2641425dfa50508100c0d--