all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Emacs (Windows version) slow when transferring large amount of text over pty or pipe
@ 2014-10-11 19:04 speech.free
  2014-10-12  1:11 ` Alexis
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: speech.free @ 2014-10-11 19:04 UTC (permalink / raw)
  To: help-gnu-emacs

I am debugging a clang based completer. The completer running as a sub-process sends a large amount of text (about 1.8M) to emacs over a pty or pipe connection. The emacs connection buffer is about 4k, as seen from logging, that is the process filter is called for every 4k of text. The text is inserted into the process buffer and accumulated there and an EOT string is repeatedly searched for. Receiving the whole transfer takes close to 30 seconds, rendering the completer useless. The same problem is not seen on Linux. Any suggestion on why this is and how to deal with it? I have GNU Emacs 24.3.1 (i386-mingw-nt6.2.9200)
 of 2013-03-17 on MARVIN.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Emacs (Windows version) slow when transferring large amount of text over pty or pipe
  2014-10-11 19:04 Emacs (Windows version) slow when transferring large amount of text over pty or pipe speech.free
@ 2014-10-12  1:11 ` Alexis
  2014-10-12  1:43 ` speech.free
       [not found] ` <mailman.11020.1413079847.1147.help-gnu-emacs@gnu.org>
  2 siblings, 0 replies; 4+ messages in thread
From: Alexis @ 2014-10-12  1:11 UTC (permalink / raw)
  To: help-gnu-emacs


speech.free@gmail.com writes:

> I am debugging a clang based completer. The completer running as a
> sub-process sends a large amount of text (about 1.8M) to emacs over a
> pty or pipe connection. The emacs connection buffer is about 4k, as
> seen from logging, that is the process filter is called for every 4k
> of text. The text is inserted into the process buffer and accumulated
> there and an EOT string is repeatedly searched for. Receiving the
> whole transfer takes close to 30 seconds, rendering the completer
> useless. The same problem is not seen on Linux. Any suggestion on why
> this is and how to deal with it? I have GNU Emacs 24.3.1
> (i386-mingw-nt6.2.9200)

Perhaps related:

https://lists.gnu.org/archive/html/emacs-devel/2014-10/msg00055.html


Alexis.



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Emacs (Windows version) slow when transferring large amount of text over pty or pipe
  2014-10-11 19:04 Emacs (Windows version) slow when transferring large amount of text over pty or pipe speech.free
  2014-10-12  1:11 ` Alexis
@ 2014-10-12  1:43 ` speech.free
       [not found] ` <mailman.11020.1413079847.1147.help-gnu-emacs@gnu.org>
  2 siblings, 0 replies; 4+ messages in thread
From: speech.free @ 2014-10-12  1:43 UTC (permalink / raw)
  To: help-gnu-emacs

Someone on Reddit has pointed out this bug:
http://lists.gnu.org/archive/html/bug-gnu-emacs/2014-10/msg00159.html

My delay largely went away after I (setq w32-pipe-read-delay 0).

On Saturday, October 11, 2014 12:04:33 PM UTC-7, speec...@gmail.com wrote:
> I am debugging a clang based completer. The completer running as a sub-process sends a large amount of text (about 1.8M) to emacs over a pty or pipe connection. The emacs connection buffer is about 4k, as seen from logging, that is the process filter is called for every 4k of text. The text is inserted into the process buffer and accumulated there and an EOT string is repeatedly searched for. Receiving the whole transfer takes close to 30 seconds, rendering the completer useless. The same problem is not seen on Linux. Any suggestion on why this is and how to deal with it? I have GNU Emacs 24.3.1 (i386-mingw-nt6.2.9200)
> 
>  of 2013-03-17 on MARVIN.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Emacs (Windows version) slow when transferring large amount of text over pty or pipe
       [not found] ` <mailman.11020.1413079847.1147.help-gnu-emacs@gnu.org>
@ 2014-10-12  4:53   ` speech.free
  0 siblings, 0 replies; 4+ messages in thread
From: speech.free @ 2014-10-12  4:53 UTC (permalink / raw)
  To: help-gnu-emacs

Thank you. This one seems to help just a little bit, but every little bit counts for a completer. Still on the same computer one would expect transferring 1.8M to be sub 1 sec instead of close to 2 sec right now.

On Saturday, October 11, 2014 6:11:30 PM UTC-7, Alexis wrote:
> > I am debugging a clang based completer. The completer running as a
> 
> > sub-process sends a large amount of text (about 1.8M) to emacs over a
> 
> > pty or pipe connection. The emacs connection buffer is about 4k, as
> 
> > seen from logging, that is the process filter is called for every 4k
> 
> > of text. The text is inserted into the process buffer and accumulated
> 
> > there and an EOT string is repeatedly searched for. Receiving the
> 
> > whole transfer takes close to 30 seconds, rendering the completer
> 
> > useless. The same problem is not seen on Linux. Any suggestion on why
> 
> > this is and how to deal with it? I have GNU Emacs 24.3.1
> 
> > (i386-mingw-nt6.2.9200)
> 
> 
> 
> Perhaps related:
> 
> 
> 
> https://lists.gnu.org/archive/html/emacs-devel/2014-10/msg00055.html
> 
> 
> 
> 
> 
> Alexis.



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-10-12  4:53 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-10-11 19:04 Emacs (Windows version) slow when transferring large amount of text over pty or pipe speech.free
2014-10-12  1:11 ` Alexis
2014-10-12  1:43 ` speech.free
     [not found] ` <mailman.11020.1413079847.1147.help-gnu-emacs@gnu.org>
2014-10-12  4:53   ` speech.free

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.