GNU bug report logs - #26397
25.1; call-process slow on macOS and slower on larger frames

Previous Next

Full log

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

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 26397 <at> debbugs.gnu.org
Subject: Re: bug#26397: 25.1;
 call-process slow on macOS and slower on larger frames
Date: Sat, 8 Apr 2017 08:47:25 -0700

On Sat, Apr 8, 2017 at 12:37 AM, YAMAMOTO Mitsuharu
<mituharu <at> math.s.chiba-u.ac.jp> wrote:
>
> Probably "fork" copies some GUI resources.  That would also explain
> why the performance is worse on the Mac port, where each frame
> allocates an extra NSWindow for overlaying.
>
> It becomes much faster and seemingly unaffected by the frame size if
> you comment out "#undef HAVE_WORKING_VFORK" and "#define vfork fork"
> in src/conf_post.h.  But I'm not sure if it is safe.

Wow, that does make a big difference. The comment says that Emacs
hangs when evaluating:

(make-comint "test0" "/nodir/nofile" nil "")

But I can not reproduce that currently with vfork. I do not understand
the second comment: "Also, setsid is not allowed in the vfork child's
context as of Darwin 9/Mac OS X 10.5."

How might I test that?

I'm happy to run with a build that has this change for a while and see
how it goes.

Perhaps this is no longer an issue in current macOS? Are there any
version specific pragmas for osx?

Previous Next

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