Of course, I've measured the time from job_start to close_cb. You can see this comparison in the example I've attached earlier in this thread.
On Aug 28, 2016 10:01 PM, "Bram Moolenaar" <[email protected]> wrote: > > 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.
