On Sunday, August 28, 2016 at 5:53:33 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
>
> > On Friday, August 26, 2016 at 7:29:58 PM UTC+3, Bram Moolenaar wrote:
> > > Ramel Eshed wrote:
> > >
> > > > On Friday, August 26, 2016 at 12:02:38 AM UTC+3, Bram Moolenaar wrote:
> > > > > Ramel Eshed wrote:
> > > > >
> > > > > > On Thursday, August 11, 2016 at 3:08:01 AM UTC+3, Ramel Eshed wrote:
> > > > > > > On Thursday, August 11, 2016 at 2:19:38 AM UTC+3, Tony Mechelynck
> > > > > > > wrote:
> > > > > > > > There are other factors which are right there in the help:
> > > > > > > > - job_start() returns a Job object and doesn't wait for the job
> > > > > > > > to finish
> > > > > > > > - system() waits for the external command to finish and returns
> > > > > > > > its
> > > > > > > > full stdout output as a string.
> > > > > > > >
> > > > > > > > I don't know Vim job control really well, but I seem to
> > > > > > > > understand
> > > > > > > > that in order to compare system() timing and job control timing
> > > > > > > > you
> > > > > > > > would have to set up callbacks to gather any output from the
> > > > > > > > channel,
> > > > > > > > and a callback to be called when the job ends (it may still
> > > > > > > > write to
> > > > > > > > stdout after it exits), and measure the time from just before
> > > > > > > > job_start() to just after making sure that all output has been
> > > > > > > > collected and that the job has ended.
> > > > > > > >
> > > > > > > > You might even, for testing purposes, try to write a System()
> > > > > > > > user
> > > > > > > > function to invoke the argument as a job and return its output
> > > > > > > > as a
> > > > > > > > string, with the disadvantage that you would completely lose job
> > > > > > > > control asynchronism. But it would allow you a better
> > > > > > > > comparison,
> > > > > > > > namely between old-fashioned system() and this new
> > > > > > > > job-control-based
> > > > > > > > System().
> > > > > > > >
> > > > > > > > Best regards,
> > > > > > > > Tony.
> > > > > > >
> > > > > > > That's exactly what I've did:
> > > > > > >
> > > > > > > func! Job()
> > > > > > > let s:rt = reltime()
> > > > > > > let g:output = []
> > > > > > > let g:job = job_start(['/bin/sh', '-c', 'cat ' .
> > > > > > > expand('%')], {'out_cb': function('s:out_cb'), 'close_cb':
> > > > > > > function('s:close_cb')})
> > > > > > > endfunc
> > > > > > >
> > > > > > > func! s:out_cb(channel, msg)
> > > > > > > call add(g:output, a:msg)
> > > > > > > endfunc
> > > > > > >
> > > > > > > func! s:close_cb(channel)
> > > > > > > echo reltimestr(reltime(s:rt))
> > > > > > > "echo g:output
> > > > > > > endfunc
> > > > > > >
> > > > > > > " compare with:
> > > > > > >
> > > > > > > func! System()
> > > > > > > let s:rt = reltime()
> > > > > > > let g:output = systemlist('cat ' . expand('%'))
> > > > > > > echo reltimestr(reltime(s:rt))
> > > > > > > endfunc
> > > > > > >
> > > > > > > """""""""""""
> > > > > > > I checked it now on my Ubuntu at home - I still see the
> > > > > > > difference but now both are much faster so even the system()
> > > > > > > delay is not noticeable. Any idea what could cause the delay on
> > > > > > > my RHEL?
> > > > > > >
> > > > > > > BTW, if I remove the comment from the 'echo g:output' line in
> > > > > > > close_cb() the message is not displayed (actually, it depends on
> > > > > > > which command is running. for the 'cat' command above -there is
> > > > > > > no message).
> > > > > >
> > > > > > Hi Bram,
> > > > > >
> > > > > > Is it possible to make system() work the same way job_start (with a
> > > > > > shell) does? As I mentioned, I get a noticeable delay with system()
> > > > > > which I don't get when using job_start(['/bin/sh'...).
> > > > >
> > > > > Not sure if there is anything to improve. Would require finding out
> > > > > why
> > > > > it's slower and whether that can be fixed.
> > > > >
> > > > > You could add channel log commands in the code in various places to
> > > > > see
> > > > > what happens.
> > > >
> > > > My problem is not with the channel, the problem is that system() is
> > > > slower than the equivalent job_start(). You can run and compare the
> > > > results of Job() and System() functions in the attached file. They are
> > > > both doing the same thing ('echo aaa') but System() is ~5 times slower
> > > > than Job() on Ubuntu and x10 slower on RHEL5.5. On RHEL System() is
> > > > extremely slow, it takes about 0.2 seconds which cause Vim to hang.
> > >
> > > I understand that. The ch_log() and other functions cn be used anywhere
> > > in the Vim code. That is in the C code, not script. So it requires
> > > adding the log calls in several places in and around the system()
> > > implementation to find out where it spends time. This requires building
> > > Vim from the modified source.
> > >
> > > --
> > > hundred-and-one symptoms of being an internet addict:
> > > 91. It's Saturday afternoon in the middle of May and you
> > > are on computer.
> > >
> > > /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net
> > > \\\
> > > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/
> > > \\\
> > > \\\ an exciting new programming language -- http://www.Zimbu.org
> > > ///
> > > \\\ help me help AIDS victims -- http://ICCF-Holland.org
> > > ///
> >
> > It looks like the delay is coming from the mch_delay(10L, TRUE) call inside
> > the for loop starting at line 4936 in os_unix.c:
> >
> > /*
> > * Similar to the loop above, but only handle X events, no
> > * I/O.
> > */
> > for (;;)
> > {
> > if (got_int)
> > {
> > /* CTRL-C sends a signal to the child, we ignore it
> > * ourselves */
> > # ifdef HAVE_SETSID
> > kill(-pid, SIGINT);
> > # else
> > kill(0, SIGINT);
> > # endif
> > got_int = FALSE;
> > }
> > # ifdef __NeXT__
> > wait_pid = wait4(pid, &status, WNOHANG, (struct rusage *)0);
> > # else
> > wait_pid = waitpid(pid, &status, WNOHANG);
> > # endif
> > if ((wait_pid == (pid_t)-1 && errno == ECHILD)
> > || (wait_pid == pid && WIFEXITED(status)))
> > {
> > wait_pid = pid;
> > break;
> > }
> >
> > /* Handle any X events, e.g. serving the clipboard. */
> > clip_update();
> >
> > mch_delay(10L, TRUE);
> > }
>
> Hmm, so 10 msec is noticeable in this case? We could use 1 msec, but it
> starts looking like a busy loop. A compromise is to start with 1 msec
> and gradually increase.
>
> --
> Bare feet magnetize sharp metal objects so they point upward from the
> floor -- especially in the dark.
>
> /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
> /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\ an exciting new programming language -- http://www.Zimbu.org ///
> \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
>From what I've seen there are 15-20 iterations of this loop, so the
>accumulated delay is about 0.2s and it is noticeable.
I've no idea what is this piece of code responsible for or if 20 iterations is
normal or not, I just wanted it to be as fast as the corresponding job_start
implementation :) (I could use job_start with a cb but in this case I need the
blocking version).
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
