Re: Unacceptable behavior -- slowing down script execution
On 09/18/2010 05:35 AM, SJ Wright wrote: Is there any reason, when bash itself nowadays has pretty good tab-completion, why bash-completion is still available in setup.exe or elsewhere in the Luniverse? Yes. Builtin bash completion ONLY targets command names (in the first shell word) and file names (in subsequent shell words). The bash-completion package adds context-sensitive tab completion (ssh TAB completes on known machine names, chown TAB completes on known user names, git branch TAB completes on branch names in the current repository, etc.). If you want the additional context sensitivity (which _I_ do), then bash-completion is a must. If you don't mind losing out on the extra context sensitivity and want bash to use less resources, then avoid bash-completion. It's up to you. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org volunteer cygwin bash-completion maintainer -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unacceptable behavior -- slowing down script execution
mike marchywka wrote: On 9/17/10, SJ Wright sjwright68 charter.net wrote: 4. Is it normal for any script to run CPU usage up to 100%? Unless it is blocking for something like IO including VM swaps, why not? Regarding #4: I have a script that I ran in GNOME Terminal less than an hour ago. I timed it -- the return was 20.6 seconds on the first line (real?). I ran the same script fifteen minutes later, evaluating identical files of the same type, length (5.37kb and 345b ASCII text) and time stamp, and after 7 minutes it was barely one-eighth complete. That's when I checked Task Manager and found my CPU usage was at 100% and three bash.exe's were running simultaneously. Admittedly the script calls on several This sounds like a threading problem if I had to guess but it could be anything that changed between runs- certainly timing will make these things come and go but having no idea what you mean by identical instead of the same there are a lot of things that could have changed etc. What did it seem to be trying to do? Often in cases like this the alarming situation is where your cpu usage drops to low values and your disk light gets stuck on as you have depleted memory. I guess I'm also not sure what you think a usual or good number of processes should be etc. A number of anecdotes have been reported about slower performance on 64 bit or multi core machines than more primitive older cmoputers and it is easy to speculate on reasons why that could happen but hard to make a clear diagnosis without an explicit test case. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple They were the same files, in terms of number of lines, bytes per line, and so forth. Likely the only differences were to be found in their timestamps. This one script seems, now that I've got rid of bash-completion (thanks again Cyrille), to be the only one that will push CPU usage to 100% and keep it there for the duration of its execution. Call me strange, but I like my Task Manager to show me no more than 51 processes at a time. I also like my scripts to call up one and only one additional instance of the shell they're written to be executed in than I'm running before I start one. I agree it's likely a threading problem, but I think it's more likely how I have the script written. A breakdown of the calls to non-internal (not BASH built-ins, so far as I can judge) would look like this: -- 8 to Exiv2 v.0.20 by Andreas Huggel. Likely there are more; I may be wrong. I don't normally keep track of which command came from where or calls on what class of ps- able process. Perhaps, as this has involved and included more than two shells running simultaneously (by visual evidence in Task Manager and nothing else), it is, instead, a matter of a too-high demand *on* the internals. Or I've got another software package, either Cygwin-adapted or just a lucky compile on my part, that's kicking in and making itself known when I launch this one particular script. I can post the script to the list as text if anyone thinks it's worth pursuing this line of logic. Thanks for the replies and the help thus far. Looking forward to the same continuing. Steve Wright -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unacceptable behavior -- slowing down script execution
On 9/17/10, SJ Wright sjwright68 charter.net wrote: 4. Is it normal for any script to run CPU usage up to 100%? Unless it is blocking for something like IO including VM swaps, why not? Regarding #4: I have a script that I ran in GNOME Terminal less than an hour ago. I timed it -- the return was 20.6 seconds on the first line (real?). I ran the same script fifteen minutes later, evaluating identical files of the same type, length (5.37kb and 345b ASCII text) and time stamp, and after 7 minutes it was barely one-eighth complete. That's when I checked Task Manager and found my CPU usage was at 100% and three bash.exe's were running simultaneously. Admittedly the script calls on several This sounds like a threading problem if I had to guess but it could be anything that changed between runs- certainly timing will make these things come and go but having no idea what you mean by identical instead of the same there are a lot of things that could have changed etc. What did it seem to be trying to do? Often in cases like this the alarming situation is where your cpu usage drops to low values and your disk light gets stuck on as you have depleted memory. I guess I'm also not sure what you think a usual or good number of processes should be etc. A number of anecdotes have been reported about slower performance on 64 bit or multi core machines than more primitive older cmoputers and it is easy to speculate on reasons why that could happen but hard to make a clear diagnosis without an explicit test case. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unacceptable behavior -- slowing down script execution
Cyrille Lefevre wrote: Le 17/09/2010 18:57, SJ Wright a écrit : 4. Is it normal for any script to run CPU usage up to 100%? a common answer about bash cpu usage is to get rid of bash-completion... if you have it installed, uninstall it, then try again. Regards, Cyrille Lefevre Thank you, Cyrille. It seems to have worked. Is there any reason, when bash itself nowadays has pretty good tab-completion, why bash-completion is still available in setup.exe or elsewhere in the Luniverse? At any rate, some effort should be made to inform new folks (to GNU-stuff) about the differences between them, and recommend against installing it -- or anything that depends on it (git-completion, acc'd. to the latest setup utility) -- if they're not going to need it for whatever they've installed Cygwin for. Something like this should be in big bold letters in the setup guide pages -- something giving the sense of bash-completion is more than tab-completion: don't confuse the two. Enough tripping off through the garden of Tangent. Cheers. Steve Wright -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Unacceptable behavior -- slowing down script execution
Hi folks. Through fits and starts, and with no more feedback from the list than Dave Korn's self-admitted wild guess about gcclib1 folders etc, my Cygwin is no longer shedding empty shell stack-dump files like dandruff. But certain things are continuing to alarm me. I'll put them in the form of questions and whoever knows the answers, please take the time to do so. 1. Is it normal behavior, once rxvt is launched, for cmd.exe to remain running as a process? 2. Using a batch-to-executable utility, I converted a customized rxvt-launching .bat file into an executable. Should this also stay open as a process in Task Manager once its work is done? 3. Is it normal behavior for one BASH script to spawn more than one subshell? 4. Is it normal for any script to run CPU usage up to 100%? Regarding #4: I have a script that I ran in GNOME Terminal less than an hour ago. I timed it -- the return was 20.6 seconds on the first line (real?). I ran the same script fifteen minutes later, evaluating identical files of the same type, length (5.37kb and 345b ASCII text) and time stamp, and after 7 minutes it was barely one-eighth complete. That's when I checked Task Manager and found my CPU usage was at 100% and three bash.exe's were running simultaneously. Admittedly the script calls on several externals, but considering the difference in completion times -- I estimate that had I not interrupted the process with ctrl-c, the Cygwin run would have taken just under 40 minutes to finish -- _and the fact that it spawned an unusual number of subshells, it doesn't speak highly for Cygwin as a viable option or means for people to keep their hand in w/re their Unix skill-sets. 5. Is this a bug peculiar to this version/build of Cygwin? I don't recall any such issues when running complicated scripts before 1.7.x. Hoping someone can answer any or all of the foregoing. Cheers, SJ Wright -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unacceptable behavior -- slowing down script execution
SJ Wright wrote: Hi folks. Through fits and starts, and with no more feedback from the list than Dave Korn's self-admitted wild guess about gcclib1 folders etc, my Cygwin is no longer shedding empty shell stack-dump files like dandruff. But certain things are continuing to alarm me. I'll put them in the form of questions and whoever knows the answers, please take the time to do so. 1. Is it normal behavior, once rxvt is launched, for cmd.exe to remain running as a process? 2. Using a batch-to-executable utility, I converted a customized rxvt-launching .bat file into an executable. Should this also stay open as a process in Task Manager once its work is done? 3. Is it normal behavior for one BASH script to spawn more than one subshell? 4. Is it normal for any script to run CPU usage up to 100%? Regarding #4: I have a script that I ran in GNOME Terminal less than an hour ago. I timed it -- the return was 20.6 seconds on the first line (real?). I ran the same script fifteen minutes later, evaluating identical files of the same type, length (5.37kb and 345b ASCII text) and time stamp, and after 7 minutes it was barely one-eighth complete. That's when I checked Task Manager and found my CPU usage was at 100% and three bash.exe's were running simultaneously. Admittedly the script calls on several externals, but considering the difference in completion times -- I estimate that had I not interrupted the process with ctrl-c, the Cygwin run would have taken just under 40 minutes to finish -- _and the fact that it spawned an unusual number of subshells, it doesn't speak highly for Cygwin as a viable option or means for people to keep their hand in w/re their Unix skill-sets. 5. Is this a bug peculiar to this version/build of Cygwin? I don't recall any such issues when running complicated scripts before 1.7.x. Hoping someone can answer any or all of the foregoing. Cheers, SJ Wright The above message:http://www.cygwin.com/ml/cygwin/2010-09/msg00568.html I have found other messages that discuss the 100% CPU load issue in previous versions of Cygwin. No wonder no one's bothered to answer my questions yet -- evidently one should take it as read that anything fancier than cmd.exe as a terminal emulator will do this. Okay, so here's QUESTION #6: Why should a bash script call up sh.exe, not once but as many as three times, as processes in Task Manager when run in the current version of Cygwin? As for the slowdown in script execution: I've pondered using ssh, scp and ftp to do all my heavier-load script running remotely to my Linux laptop. QUESTION #7: Am I the only one who thinks this shouldn't be necessary? Here's hoping I've piqued someone's interest. Cheers again, SJ Wright -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unacceptable behavior -- slowing down script execution
On 9/17/2010 6:46 PM, SJ Wright wrote: The above message:http://www.cygwin.com/ml/cygwin/2010-09/msg00568.html I have found other messages that discuss the 100% CPU load issue in previous versions of Cygwin. No wonder no one's bothered to answer my questions yet -- evidently one should take it as read that anything fancier than cmd.exe as a terminal emulator will do this. Okay, so here's QUESTION #6: Why should a bash script call up sh.exe, not once but as many as three times, as processes in Task Manager when run in the current version of Cygwin? As for the slowdown in script execution: I've pondered using ssh, scp and ftp to do all my heavier-load script running remotely to my Linux laptop. QUESTION #7: Am I the only one who thinks this shouldn't be necessary? Here's hoping I've piqued someone's interest. Here's a thought: Problem reports: http://cygwin.com/problems.html -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
