all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: York Zhao <gtdplatform@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: help-gnu-emacs@gnu.org
Subject: Re: `start-process' awfully slow
Date: Sat, 20 Apr 2013 13:03:53 -0400	[thread overview]
Message-ID: <CAD3zm21gN2WqB7XCSGvySRk7CAXw19t6dQ77_ycF8+2UTtG0PA@mail.gmail.com> (raw)
In-Reply-To: <jwvppxxf018.fsf-monnier+emacs@gnu.org>

>> As mentioned above, when `call-process' is used, it takes 2 seconds
>> for Clang to generate 15,000 lines of completion results and then the
>> results gets received by Emacs in a temporary buffer. 2 seconds is
>> painful but still OK.
>
> Which part of those 2 seconds is due to clang, and which part to Emacs?

I don't know exactly the proportion of time being consumed, but I think most of
the 2 seconds are consumed by the clang program. Is there an easy way to know
exactly how long haven been consumed by Emacs to receive the output from clang?

>> Because of the slowness, I tried to add the functionality to be able
>> to call Clang asynchronously so that the keyboard input will not be
>> blocked while awaiting the completion results. What had driven me
>> crazy is that it takes more than 15 seconds for Emacs to receive the
>> 15,000 lines of completion results if `start-process' is is being used
>> to call the Clang executable. During this 15 seconds I was not typing
>> anything so Emacs is "idling". The question is why `start-process'
>> takes 15 seconds while `call-process' takes only 2 seconds, and what
>> can I do about it?

> I assume those lines aren't terribly long.

The longest line had exceeded 200, I noticed this because there had been a time
I had to set `line-number-display-limit-width' to over 200 (default being 200)
in order for `column-number-mode' to be able to display the column number if the
maximum length of lines in a buffer exceeds 200.

> so we might be talking about less than 1MB of data

The size is actually 1.4MB.

> I suggest you report it as a bug (via M-x report-emacs-bug), trying to provide
> as much info as possible to make it reproducible (e.g. replacing clang with a
> "cat" that simply outputs those 15K lines).

Replacing "clang" with "cat" is a good idea to reproduce the problem. I might
have to report the bug, thanks for your suggestion.

Thanks,

York

On Sun, Apr 14, 2013 at 2:24 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> As mentioned above, when `call-process' is used, it takes 2 seconds
>> for Clang to generate 15,000 lines of completion results and then the
>> results gets received by Emacs in a temporary buffer. 2 seconds is
>> painful but still OK.
>
> Which part of those 2 seconds is due to clang, and which part to Emacs?
>
>> Because of the slowness, I tried to add the functionality to be able
>> to call Clang asynchronously so that the keyboard input will not be
>> blocked while awaiting the completion results. What had driven me
>> crazy is that it takes more than 15 seconds for Emacs to receive the
>> 15,000 lines of completion results if `start-process' is is being used
>> to call the Clang executable. During this 15 seconds I was not typing
>> anything so Emacs is "idling". The question is why `start-process'
>> takes 15 seconds while `call-process' takes only 2 seconds, and what
>> can I do about it?
>
> There's no doubt that start-process has to work harder than
> call-process, but 13s to transfer 15K lines (I assume those lines aren't
> terribly long, so we might be talking about less than 1MB of data) is
> too long.  I suggest you report it as a bug (via M-x report-emacs-bug),
> trying to provide as much info as possible to make it reproducible
> (e.g. replacing clang with a "cat" that simply outputs those 15K lines).
>
>
>         Stefan



      reply	other threads:[~2013-04-20 17:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-13 15:31 `start-process' awfully slow York Zhao
2013-04-14 18:24 ` Stefan Monnier
2013-04-20 17:03   ` York Zhao [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAD3zm21gN2WqB7XCSGvySRk7CAXw19t6dQ77_ycF8+2UTtG0PA@mail.gmail.com \
    --to=gtdplatform@gmail.com \
    --cc=help-gnu-emacs@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.