Ramel Eshed wrote:
> 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 -- [email protected] -- 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 -- [email protected] -- 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).
Hmm, so my patch won't make much difference. Perhaps you are measuring
the difference between starting the job and when it's finished?
Then obviously it will take longer. I thought that with job_start() you
would also wait, otherwise we are comparing apples and bananas.
--
>From "know your smileys":
:-* A big kiss!
/// Bram Moolenaar -- [email protected] -- 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 ///
--
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
