GNU bug report logs - #1578
23.0.60; [EmacsCarbon] emacsclient -c make emacs very slow (under Mac OSX)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 1578 in the body.
You can then email your comments to 1578 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: poppyer <poppyer <at> gmail.com>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.60; [EmacsCarbon] emacsclient -c make emacs very slow (under Mac OSX)
Date: Sun, 14 Dec 2008 11:55:04 +0800

First, I use emacs -nw to open a normal emacs in the terminal.  Then I
use emacsclient -c to open a carbon frame.  Now the terminal emacs
becomes very slow and unresponsive. (But the CPU is not running high).
Even after the carbon frame is closed, it is still same slow. (and I
have to close emacs and restart)




In GNU Emacs 23.0.60.1 (i386-apple-darwin9.5.0, NS apple-appkit-949.35)
 of 2008-12-11 on neutron.local
Windowing system distributor `Apple', version 97.112.112.108.101.45.97.112.112.107.105.116.45.57.52.57.46.51.53
configured using `configure  '--with-ns''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: zh_CN.UTF-8
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: @im=fcitx
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Summary

Minor modes in effect:
  gnus-agent-mode: t
  erc-log-mode: t
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-netsplit-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  iswitchb-mode: t
  recentf-mode: t
  which-function-mode: t
  show-paren-mode: t
  mouse-sel-mode: t
  global-hl-line-mode: t
  pinbar-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
RET ESC x n e w s C-p C-p RET q n n n n n p p RET SPC 
n SPC C-n SPC n q p p RET C-n C-n C-n C-n C-n C-p C-p 
C-p SPC SPC C-n SPC SPC C-n SPC c y p n n n n n n n 
n n n n n p p p p p p p p p n n n n n p p p p p n n 
n n n n p p p n n n p RET SPC q RET C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-p c y p p p p n RET SPC n n c y ESC [ 
B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC 
[ A ESC [ A ESC [ A ESC [ A ESC [ A ESC [ A ESC [ A 
p n RET SPC q p RET SPC q p RET SPC SPC C-n SPC SPC 
q C-c C-@ C-c C-@ C-c C-@ ESC 1 C-p C-p C-p C-p C-p 
C-p ESC g n RET SPC n C-x 1 ESC x b DEL s u b TAB ESC 
DEL ESC DEL e m TAB a TAB s u m i TAB TAB ESC DEL r 
e TAB ESC DEL ESC DEL r e p o TAB r TAB e DEL TAB 
RET

Recent messages:
Generating summary...done
Reading active file from gmail via nnimap...
nnimap: Checking mailboxes...done
Reading active file from freenews.netfront.net via nntp...
Checking new news...done
Retrieving newsgroup: nntp+freenews.netfront.net:cn.bbs.comp.emacs...
Fetching headers for nntp+freenews.netfront.net:cn.bbs.comp.emacs...done
Scoring...done
Generating summary...done
Making completion list... [2 times]

Message #12 received at 1578 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: 1578 <at> debbugs.gnu.org
Cc: poppyer <poppyer <at> gmail.com>
Subject: Re: emacsclient -c make emacs very slow (under Mac OSX)
Date: Thu, 22 Jan 2009 01:02:45 +0200

> First, I use emacs -nw to open a normal emacs in the terminal.  Then I
> use emacsclient -c to open a carbon frame.  Now the terminal emacs
> becomes very slow and unresponsive. (But the CPU is not running high).
> Even after the carbon frame is closed, it is still same slow. (and I
> have to close emacs and restart)

This is because the events are being passed only after a full run  
through the NS event loop.  See line 3194 in nsterm.m (the first one  
of ns_select()).  Ideally this would drop down to the regular select 
() if the NS application ("carbon" frame) is not active.  However, I  
haven't found a way to detect this without also causing the problem  
of failing to pick up the app becoming active again until after a  
long delay.  I think the select() gets called with a long timeout  
and, no matter if cocoa-experimental-ctrl-g is set or not, no  
interruption of it happens.

Since there is only one thread, an external call to, e.g. - 
applicationWillBecomeActive won't go through until after this select  
terminates.

Message #17 received at 1578 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: poppyer <poppyer <at> gmail.com>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: 1578 <at> debbugs.gnu.org
Subject: Re: emacsclient -c make emacs very slow (under Mac OSX)
Date: Sat, 07 Feb 2009 02:26:50 +0800

Adrian Robert <adrian.b.robert <at> gmail.com> writes:

>> First, I use emacs -nw to open a normal emacs in the terminal.  Then I
>> use emacsclient -c to open a carbon frame.  Now the terminal emacs
>> becomes very slow and unresponsive. (But the CPU is not running high).
>> Even after the carbon frame is closed, it is still same slow. (and I
>> have to close emacs and restart)
>
> This is because the events are being passed only after a full run
> through the NS event loop.  See line 3194 in nsterm.m (the first one
> of ns_select()).  Ideally this would drop down to the regular select
> () if the NS application ("carbon" frame) is not active.  However, I
> haven't found a way to detect this without also causing the problem
> of failing to pick up the app becoming active again until after a
> long delay.  I think the select() gets called with a long timeout
> and, no matter if cocoa-experimental-ctrl-g is set or not, no
> interruption of it happens.
>
> Since there is only one thread, an external call to, e.g. -
> applicationWillBecomeActive won't go through until after this select
> terminates.


I notice that if I start with "emacs -nw", there is no NSApp (no icon in
the osx dock). When I use "emacsclient -c" to open a NS frame, the icon
shows up. My idea here is, if I close every NS frame, can we destroy the
NSApp and make it nil again (say by testing the frame count) ? If this
is possible, it at least make emacsclient more usable; and I don't need
to restart Emacs.

Cheers,
poppyer

Message #22 received at 1578 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: poppyer <poppyer <at> gmail.com>
Cc: 1578 <at> debbugs.gnu.org
Subject: Re: emacsclient -c make emacs very slow (under Mac OSX)
Date: Sat, 7 Feb 2009 12:37:19 +0200

On Feb 6, 2009, at 8:26 PM, poppyer wrote:

> I notice that if I start with "emacs -nw", there is no NSApp (no  
> icon in
> the osx dock). When I use "emacsclient -c" to open a NS frame, the  
> icon
> shows up. My idea here is, if I close every NS frame, can we  
> destroy the
> NSApp and make it nil again (say by testing the frame count) ? If this
> is possible, it at least make emacsclient more usable; and I don't  
> need
> to restart Emacs.

This a good idea and would probably meet better with user  
expectations when the only frame is closed (get rid of the icon in  
the dock), also applicable when started with --daemon.

I don't have time to work on it right now, so if someone else wants  
to take a crack.. it shouldn't be that hard (though there could be  
unexpected gotchas I guess)...

Message #27 received at 1578 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: 1578 <at> debbugs.gnu.org, poppyer <poppyer <at> gmail.com>
Subject: Re: bug#1578: emacsclient -c make emacs very slow (under Mac OSX)
Date: Sat, 07 Feb 2009 10:26:10 -0500

>> I notice that if I start with "emacs -nw", there is no NSApp (no icon in
>> the osx dock). When I use "emacsclient -c" to open a NS frame, the icon
>> shows up. My idea here is, if I close every NS frame, can we destroy the
>> NSApp and make it nil again (say by testing the frame count) ? If this
>> is possible, it at least make emacsclient more usable; and I don't need
>> to restart Emacs.

> This a good idea and would probably meet better with user expectations when
> the only frame is closed (get rid of the icon in  the dock), also applicable
> when started with --daemon.

> I don't have time to work on it right now, so if someone else wants to take
> a crack.. it shouldn't be that hard (though there could be  unexpected
> gotchas I guess)...

Odd: I'm not a regular Mac OS X user, but from the little bit of
exposure I've had to this system, I would have expected the exact
opposite: I'd have expected "emacs --daemon" to bring up the Emacs icon
in the dock even before the first frame is opened, and would stay there
until the daemon exits.


        Stefan

Message #30 received at 1578 <at> debbugs.gnu.org (full text, mbox):

From: Hagmonk <hagmonk <at> icloud.com>
To: 1578 <at> debbugs.gnu.org
Subject: Re: bug#1578: emacsclient -c make emacs very slow (under Mac OSX)
Date: Sat, 05 Mar 2016 19:38:59 -0800

I’m unable to reproduce this bug using Emacs 25.0.92.2 on OS X 10.11.3.

nsterm.m has been reworked somewhat over the past 6 years, including ns_read_socket which I believe is the function in question based on the conditional it used to have to check whether it was “inNsSelect”.

I’d suggest returning this to the reporter for verification.

Message #35 received at 1578 <at> debbugs.gnu.org (full text, mbox):

From: Andrew Hyatt <ahyatt <at> gmail.com>
To: Hagmonk <hagmonk <at> icloud.com>
Cc: 1578 <at> debbugs.gnu.org
Subject: Re: bug#1578: emacsclient -c make emacs very slow (under Mac OSX)
Date: Fri, 25 Mar 2016 22:32:48 -0400

Seeing how this was marked unreproducible for a few weeks now, I'm going
to close this out.  Someone can re-open if it still can reproduce on Emacs
25.

Hagmonk <hagmonk <at> icloud.com> writes:

> I’m unable to reproduce this bug using Emacs 25.0.92.2 on OS X 10.11.3.
>
> nsterm.m has been reworked somewhat over the past 6 years, including
> ns_read_socket which I believe is the function in question based on the
> conditional it used to have to check whether it was “inNsSelect”.
>
> I’d suggest returning this to the reporter for verification.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.