Re: [ANNOUNCEMENT] Updated: cygwin-1.7.10-1
Corinna Vinschen corinna-cygwin at cygwin.com writes: - Improve fork/exec performance on 64 bit systems. If fork/exec became faster, something else has slowed down noticeably on my 64-bit Vista system. Using a fairly fork-heavy build script as the benchmark (and running it when nothing needs to be re-built), 1.7.10 is about 25% slower. Switching to cygwin1.dll 1.7.9 speeds things up again (and I only changed the DLL; it seemed to work fine for this test at least). The while [ 1 ]; do date; done | uniq -c loop is about 15% faster with 1.7.10 though. Lines like these stand out in a quick look in the strace log (about 75 MB): 1172898 1173730 [main] sh 1484 child_copy: dll bss - hp 0xEC low 0x611FC000, high 0x61230770, res 1 Every 4-5 print of child_copy: dll bss starts with a big number like that (values in the 5-10 range are more common). Don't know if this is relevant... Magnus -- 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
BLODA addition? IntelliPoint 8.15
Hi, Seems like Microsoft's driver IntelliPoint 8.15 64-bit for Windows Vista can cause frequent STATUS_ACCESS_VIOLATION errors. Version 8.0 works fine though. Just thought I should mention it, in case someone else sees a sudden rash of STATUS_ACCESS_VIOLATION. Magnus -- 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
[PATCH] Faster process initialization
This patch speeds up process initialization on 64-bit systems. Maybe
the comment Initialize signal processing here ... should be re-worded
or removed completely.
The speed difference can be noticeable.
while (true); do date; done | uniq -c manages more than 3 times more
date executions per second on my system.
2010-09-01 Magnus Holmgren magnus...@gmail.com
* dcrt0.cc (dll_crt0_0): Remove call to sigproc_init. It creates
a thread, and execution of that thread can be delayed during
DLL init, slowing things down (seen on 64-bit systems).
(dll_crt0_1): Always call sigproc_init.
Index: src/winsup/cygwin/dcrt0.cc
===
RCS file: /cvs/src/src/winsup/cygwin/dcrt0.cc,v
retrieving revision 1.382
diff -u -p -r1.382 dcrt0.cc
--- src/winsup/cygwin/dcrt0.cc 30 Aug 2010 23:23:28 - 1.382
+++ src/winsup/cygwin/dcrt0.cc 1 Sep 2010 17:49:26 -
@@ -740,11 +740,9 @@ dll_crt0_0 ()
}
}
- /* Initialize signal processing here, early, in the hopes that the creation
- of a thread early in the process will cause more predictability in memory
- layout for the main thread. */
- if (!dynamically_loaded)
-sigproc_init ();
+ /* Don't initialize signal processing here. It creates a thread, and
+ execution of threads created during DLL initialization can be
+ delayed (e.g., on 64-bit Windows Vista and Windows 7) */
user_data-threadinterface-Init ();
@@ -789,8 +787,10 @@ dll_crt0_1 (void *)
{
extern void initial_setlocale ();
- if (dynamically_loaded)
-sigproc_init ();
+ /* Initialize signal processing here, early, in the hopes that the creation
+ of a thread early in the process will cause more predictability in memory
+ layout for the main thread. */
+ sigproc_init ();
check_sanity_and_sync (user_data);
/* Initialize malloc and then call user_shared_initialize since it relies
--
Magnus
Re: Cygwin slow on x64 systems
Magnus Holmgren magnushol at gmail.com writes: I did some testing on my 64-bit Vista system, and it appears that CreateThread is the main cause. I think I've found the reason for the slow CreateThread. It seems like the following remark in the MSDN documentation is relevant, at least for WOW64 processes: * During process startup and DLL initialization routines, new threads can be created, but they do not begin execution until DLL initialization is done for the process. To test this, I removed the call to sigproc_init in dll_crt0_0 and made sure it was always called in dll_crt0_1 instead. Suddenly the sigp thread started executing immediately, and its initialization was complete long before wait_for_sigthread was called. Even with this change, a date loop isn't blazingly fast on my computer (cygwin1.dll created from 1.7.7 sources, first number is executions per second): 26 Wed Sep 1 18:47:36 WEDT 2010 27 Wed Sep 1 18:47:37 WEDT 2010 26 Wed Sep 1 18:47:38 WEDT 2010 But it is a clear improvement (using the stock 1.7.6 dll): 9 Wed Sep 1 18:52:35 WEDT 2010 9 Wed Sep 1 18:52:36 WEDT 2010 9 Wed Sep 1 18:52:37 WEDT 2010 PS. There are a few trace printfs in cygthread::create that uses name in the argument list to print the thread name. That doesn't work nearly as well as __name. :) Magnus -- 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: Cygwin slow on x64 systems
Eric Blake eblake at redhat.com writes: I did some testing on my 64-bit Vista system, and it appears that CreateThread is the main cause. To test this, I removed the call to sigproc_init in dll_crt0_0 and made sure it was always called in dll_crt0_1 instead. Suddenly the sigp thread started executing immediately, and its initialization was complete long before wait_for_sigthread was called. Since you obviously have a patch, would you mind sharing it, rather than just your conclusions from said patch? Not quite ready for commit as is, but here it is: Index: src/winsup/cygwin/dcrt0.cc === RCS file: /cvs/src/src/winsup/cygwin/dcrt0.cc,v retrieving revision 1.382 diff -r1.382 dcrt0.cc 746,747c746,747 if (!dynamically_loaded) sigproc_init (); --- //if (!dynamically_loaded) //sigproc_init (); 792c792 if (dynamically_loaded) --- //if (dynamically_loaded) Magnus -- 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: Cygwin slow on x64 systems
Christopher Faylor cgf-use-the-mailinglist-please at cygwin.com writes: Here's what I'm saying: It makes absolutely no sense that moving the call would have any effect. The code is the way it is for a reason so we're not going to just revert the change. I think it makes sense, if the signal thread initialization takes time. Which it does: 69 15954 [main] date 2708 wait_for_sigthread: wait_sig_inited 0x4C 13706 29660 [main] date 2708 wait_for_sigthread: process/signal handling enabled, state 0x41 146 29806 [sig] date 2708 wait_sig: entering ReadFile loop, my_readsig 0xFC, my_sendsig 0x100 The above is a snippet from strace date (with some wrapping by me), using Cygwin 1.7.6 on Vista x64. And 1.7.7 is said to be slower still - and guess what, sigproc_init is called later; see r1.382 of dcrt0.cc. Magnus -- 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: Cygwin slow on x64 systems
Sagi Ben-Akiva sagi at graphtech.co.il writes: For the last couple of weeks I'm trying to identify the cause for cygwin slowdown on x64 machines which was reported by David Morgan about 6 months ago. ... Any help will be appreciated. I did some testing on my 64-bit Vista system, and it appears that CreateThread is the main cause. I added a few traces, and got this: $ strace --mask=thread,sigp date 149 149 [main] date 2944 cygthread::create: name ... 159 308 [main] date 2944 cygthread::create: created name ... 62416549 [main] date 2944 wait_for_sigthread: wait_sig_inited 0xB0 23606 30155 [sig] date 2944 cygthread::stub: cygthread::stub enter 111 30266 [sig] date 2944 cygthread::stub: cygthread::stub callfunc 65 30331 [sig] date 2944 cygthread::callfunc: wait for 'h' 59 30390 [sig] date 2944 cygthread::callfunc: func 65 30455 [sig] date 2944 init_sig_pipe: enter 5343 35798 [sig] date 2944 init_sig_pipe: create pipe 134 35932 [sig] date 2944 init_sig_pipe: exit 72 36004 [sig] date 2944 wait_sig: entering ReadFile loop ... 4 36008 [main] date 2944 wait_for_sigthread: process/signal ... The second trace line is printed after CreateThread has returned, and the fourth line is the first thing executed in the new thread (don't know if it is a good idea to trace that early in the thread, but...). Magnus -- 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: 1.7: cygdrive files readonly by default
Vince Indriolo vinceind at gmail.com writes: There is definitely something not right with my setup. I have 64-bit Windows 7 e:\echo foo foo e:\c:\cygwin\bin\ls.exe -l foo --+ 1 vince None 6 Sep 2 17:28 foo $ ls -l foo --+ 1 vince None 6 Sep 2 17:28 foo Interesting. The other day I noticed the same problem on Windows Vista (32 and 64 bit), when unpacking archives (e.g., when not using the Cygwin version of 7-zip). Interesting... When I list the files using a DOS path (say, 'ls -l foo\\bar' instead of 'ls -l foo/bar'), they do get proper permissions. :) -- 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
sh.exe: TP_NUM_W_BUFS too small?
When running configure scripts, I sometimes see this error message repeated several times, for different lines of the configure script: bin\sh.exe: *** fatal error - Internal error: TP_NUM_W_BUFS too small. I saw this when building libsdl 1.2.13 on Cygwin 1.7 (uname -v reports 2009-07-13 10:28) on 64-bit Vista SP2. The configure script seem to have succeeded anyway (the build completes and libsdl works). So, is it really an error? -- 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: sh.exe: TP_NUM_W_BUFS too small?
Corinna Vinschen corinna-cygwin at cygwin.com writes: Yes, it is definitely a bug. AFAICS this occurs when a process forks too deeply (child forks, grandchild forks again, etc, without execing). The fork() setjmp/longjmp magic accidentally skipped the cleanup destructor which is supposed to free the temporary thread-local buffers. This doesn't matter if the child process execs, as usual, but it matters a lot as soon as the forked child forks further and further, so the thread-local buffers become a sparse resource. When I looked closer at the script causing the message (not configure as such, but called from configure) it happened in a function that called itself recursively. A few (2-3) levels down the error starts appearing. Magnus -- 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: [ANNOUNCEMENT] [1.7] Updated: cygwin-1.7.0-47
Corinna Vinschen corinna-cygwin at cygwin.com writes: This -47 release is accompanied by a new setup-1.7.exe installer, version number is 2.617. I get consistent crashes sometimes after install (and before running postinstall scripts?). Exception code is 0xc0fd (stack overflow? Fault offset is 0x000430ac, in case that helps). Even a run without actually installing anything triggers it. 2.609 works fine. Seen on Vista Home Premium 64-bit and Vista Business 32-bit. By the way, I don't like that setup maximizes the window when on the package selection step. An option somewhere to disable it would be nice. :) Magnus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] [1.7] Updated: cygwin-1.7.0-47
Matthias Andree matthias.andree at gmx.de writes: By the way, I don't like that setup maximizes the window when on the package selection step. An option somewhere to disable it would be nice. :) But that's actually a useful feature. The default size used to be way too small. It's just that I think maximized is too big (especially on a 24 inch screen). Magnus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: /dev/null timing and clock skew problems
Aaron Gray writes: The #if statement starting on that line is just for the three second clearance. I use it on a local build of Make and it seems to work well. The file has modification time 0.0096 s in the future were harmless. But the Clock skew detected. Your build may be incomplete. can possibly indicate an incomplete build. This seems to be a problem on my slower machine XP, but not on my newer Vista one. Were you getting clock skew problems too ? Yes, but they were caused by the imprecise file times (which triggers the clock skew message), as I was building on a FAT32 partition. Enabling the code in the #if statement fixed the file time issue, which only happened for files that were created during the build. Magnus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: /dev/null timing and clock skew problems
Aaron Gray writes: The code for this is available in standard Make, but it isn't enabled in the current build on Cygwin. (The code can be found in remake.c, at line 1277. It's currently enabled if WINDOWS32 or __MSDOS__ is defined.) Is this just the three second clearance or something more substantial that will guarentee builds ? The #if statement starting on that line is just for the three second clearance. I use it on a local build of Make and it seems to work well. Magnus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: /dev/null timing and clock skew problems
Pedro Alves writes: No, but I'm on FAT32 on this machine. Problem is described here: http://www.delorie.com/djgpp/v2faq/faq22_18.html According to that same page, DJGPP has a local hack^Wpatch to suppress that warning: DJGPP ports of GNU Make v3.77 and later allow for up to 3 seconds of positive difference between the file timestamp and the system clock (that is, the file is allowed to be up to 3 seconds into the future), before the above warning is printed. So upgrading to the latest version of Make should eliminate such bogus warnings and leave you only with messages due to real clock skews. The code for this is available in standard Make, but it isn't enabled in the current build on Cygwin. (The code can be found in remake.c, at line 1277. It's currently enabled if WINDOWS32 or __MSDOS__ is defined.) Magnus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin slower on one computer
Christian Franke wrote: The root of the problem is the host intrusion prevention system driver khips.sys. Even if this feature is turned off (or unavailable in the free version), the driver keeps running and slows down fork() considerably. (It probably hooks somewhere into Read/WriteProcessMemory()) Stopping the firewall service does not help. Only stopping the driver (sc stop khips) or uninstalling KPF helps. Interesting. Didn't know it could be turned off more effectively. Unfortunately, that doesn't fix all of the slowdown KPF causes for me. I think the program file checksumming done in the application behavior blocking causes the rest (making my test case take almost twice as long to run, even with the behavior blocking turned off). Didn't find any service to really disable that. Magnus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin slower on one computer
Magnus Holmgren wrote: I'm trying to figure out why Cygwin build things so much slower on one computer I have. We're talking about more than 3 times slower on a computer that ought to be a bit faster (Athlon64 at 2.2-2.4 GHz, compared to a Pentium M at 1.8 GHz). This is a little embarrassing, but I finally found out what caused the large speed difference. You might've guessed it: the firewall. In this case, it was the Kerio Personal Firewall. I'm guessing it is the host intrusion prevention system module that causes it (not that I had it enabled). When using the Windows built-in firewall (same as on the Pentium M system), the Athlon system is indeed a bit faster. Magnus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin slower on one computer
Hugh McMaster wrote: Have you tried enabling the large Windows memory cache option? This should increase your Cygwin compile time immensely. The build time is also related, as you know, to what else is taking CPU time. No, I haven't, as the test isn't (or shouldn't be) I/O bound. The first run can be a bit slower, but following runs are quicker, and appear to run entirely from the filesystem cache (and those are the ones I timed). And I've run the tests on an idle system. Magnus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin slower on one computer
Magnus Holmgren wrote: I'm trying to figure out why Cygwin build things so much slower on one computer I have. We're talking about more than 3 times slower on a computer that ought to be a bit faster (Athlon64 at 2.2-2.4 GHz, compared to a Pentium M at 1.8 GHz). After some more digging - and a bit of feedback off-list - I get the feeling (in the cases I've noticed at least) that the speed difference is mainly explained by the following reasons (in no particular order): * fork is expensive. * vfork is just a wrapper for fork on cygwin. * fork is much more expensive on AMD than on Intel. The third one is the one I'm most unsure about, as I only really have data about one Intel architecture (the Pentium M). But on the AMD system, the page fault delta (as reported by Process Explorer) during a build is a little more than 10,000 per second, while on the Intel system, the page fault delta can go to 30,000 per second. (Anyone who knows how SFU implements (v)fork? :) Magnus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin slower on one computer
Hi, I'm trying to figure out why Cygwin build things so much slower on one computer I have. We're talking about more than 3 times slower on a computer that ought to be a bit faster (Athlon64 at 2.2-2.4 GHz, compared to a Pentium M at 1.8 GHz). After digging into strace logs a bit, it seems like the Athlon is a bit faster at first, but after a while (after creating a bunch of child processes?), things change, making it a bit slower. Mostly not too much, around 10-20% or so, but sometimes about 100%. And there's one step where this could make things really bad. During startup of a program, lines like the following are displayed (some whitespace editing done): 59 294 [main] make 2936 child_copy: dll data - hp 0x6BC low 0x6110, high 0x61104BA0, res 1 157457 157751 [main] make 2936 child_copy: dll bss - hp 0x6BC low 0x6113F000, high 0x611483E0, res 1 205 157956 [main] make 2936 child_copy: user heap - hp 0x6BC low 0x68, high 0x6A, res 1 25 157981 [main] make 2936 child_copy: done Now, that dll bss copy time fluctuates quite a bit, so in one case (from the Athlon computer) the time is 32146275... (It might be worth mentioning that the log in question is some 35 MB. Maybe that can throw the timing off a bit?) Any ideas what could cause this slowdown? Could the child_copy part be involved? Since it involves the Win32 functions ReadProcessMemory/WriteProcessMemory, I imagine it could impact performance noticeably, in unpredictable ways (since it would need to mess around with memory protection stuff). One thing that suggests something strange is going on is the fact that if I have a background process running (like [EMAIL PROTECTED] (which doesn't affect the build time, btw)), the CPU load drops noticably (according to Process Explorer), from 100% to something like 75-85%. I've tried disabling anti-virus, firewalls, background processes and the like, but it has little to no impact on the build times. Magnus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin finally installed on vista but now other errors
Mike Knope wrote: 191 [main] xterm 3256 child_copy: linked dll data write copy failed, 0x2AB000..0x2AB440, done 0, windows pid 2273236, Win32 error 487 AFAIK, you need to be a member of the debugger users group (or be an admin) for child_copy to work. Magnus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Tab completion list takes enormously long time to generate from empty string
Mangus, At 16:12 2003-01-13, Magnus Holmgren wrote: -Original Message- From: Magnus Holmgren [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 7:51 PM To: [EMAIL PROTECTED] Subject: Tab completion list takes enormously long time to generate from empty string Greetings. When I press tab in bash without having typed anything at all (which is somewhat abusive but it easily happens), bash works for 15 minutes, going through $PATH looking for executables (and in the end producing nothing) on a 2x450 MHz PIII. Is that normal? The time consumed in this sort of thing is almost certainly dominated by I/O activity, not CPU load. Well, there are certainly some disk I/O, but also 100% load on one processor, so the operation seems to be CPU-bound anyway. How long does it take Cygwin Setup to compute the list of packages that are candidates for download or installation? If your 15 minute time to produce a list of executables for command completion is any indication, it must be hours! A few seconds. Bite that! :) But Cygwin setup doesn't have to open and read thousands of files. And it's not using cygwin1.dll. The Cygwin layer seems to slow down things considerably. On my 2.4 GHz single processor system with fast disks, it takes only a few seconds to get the beep on the first tab and only about a second or two to be asked if I want to see all 3719 possibilities on the second tab. I was able to strip down my $PATH a bit (removing KDE for example), reducing the time needed to generate the list to some minute, but I'm not quite satisfied with that either. It's too bad so many DLLs are produced in this list. Must they have execute bits set to be loaded? NT does have separate read and execute bits. I don't know if DLL:s have to have the execute bits set to be loaded, but it's rather laborious to change all the permissions anyway. Windows primarily relies on extensions to determine what files are executable, as you know. Perhaps cygwin should do that as well, i.e. only check files with known extensions for #!/path? Correction; there is no writing to disk, but certainly loads of *reading*, and quicksort seems to be used, so I don't blame the sorting anymore. I reckon that all files in $PATH (except .exe-s) have to be opened to see if they start with #!, and that that takes some time. Getting rid of some entries in $PATH surely reduces the time consumed, but I still think that more than five seconds is too much. Any perceptible delay in getting a result from a computer is too long. So it goes... Hey! I didn't say that! I'll be fine with ten seconds! :-) Some optimizations should be possible, such as only checking files with certain extensions, like .sh, .pl, and none at all for the magic #! or caching the list in some form. A second option might even be to disallow tab completion of commands without entering a prefix. This is the sort of thing the -x, -E and -X options to mount are meant to address. Check them out, they can probably help a lot with this problem. It helps a bit, or even a lot, but at the price that all files will be tab completed to. Unless I create a mount point to each directory in $PATH. /Magnus Randall Schulz /Magnus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Tab completion list takes enormously long time to generate from empty string
Greetings. When I press tab in bash without having typed anything at all (which is somewhat abusive but it easily happens), bash works for 15 minutes, going through $PATH looking for executables (and in the end producing nothing) on a 2x450 MHz PIII. Is that normal? My $PATH contains the usual /usr/local/bin:/usr/bin:/bin, the WINNT and System32 directories, plus some relatively neglectable ones (18 directories in total), but the number of directories in the path and the time it takes to go through their contents is not the problem. Matching an executable in the last directory in $PATH only takes about 0.2 s. Instead, the huge size of the resulting list seems to be what causes the delay, especially when considering that no disk I/O at all is performed during 14 min 59 sec of the 15 minutes... I suspect that someone has chosen a sorting algorithm with time complexity O(N^2). Or O(2^N)... Maybe I can find that out myself. Cheers, Magnus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Tab completion list takes enormously long time to generate from empty string
-Original Message- From: Magnus Holmgren [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 7:51 PM To: [EMAIL PROTECTED] Subject: Tab completion list takes enormously long time to generate from empty string Greetings. When I press tab in bash without having typed anything at all (which is somewhat abusive but it easily happens), bash works for 15 minutes, going through $PATH looking for executables (and in the end producing nothing) on a 2x450 MHz PIII. Is that normal? My $PATH contains the usual /usr/local/bin:/usr/bin:/bin, the WINNT and System32 directories, plus some relatively neglectable ones (18 directories in total), but the number of directories in the path and the time it takes to go through their contents is not the problem. Matching an executable in the last directory in $PATH only takes about 0.2 s. Instead, the huge size of the resulting list seems to be what causes the delay, especially when considering that no disk I/O at all is performed during 14 min 59 sec of the 15 minutes... I suspect that someone has chosen a sorting algorithm with time complexity O(N^2). Or O(2^N)... Maybe I can find that out myself. Cheers, Magnus Correction; there is no writing to disk, but certainly loads of *reading*, and quicksort seems to be used, so I don't blame the sorting anymore. I reckon that all files in $PATH (except .exe-s) have to be opened to see if they start with #!, and that that takes some time. Getting rid of some entries in $PATH surely reduces the time consumed, but I still think that more than five seconds is too much. Some optimizations should be possible, such as only checking files with certain extensions, like .sh, .pl, and none at all for the magic #! or caching the list in some form. A second option might even be to disallow tab completion of commands without entering a prefix. /Magnus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
BUG: Mounts to root directories causes setup.exe to crash
Greetings! The cygwin installer, setup.exe, crashes when trying to install files to a directory which has been mounted to the root directory of a drive. Setup.exe must of course look at the mounts recorded in the registry to install files in the correct places. However, when you mount a cygwin directory, such as /etc, on the root directory of a partition, like e:\, regardless of whether it's done with the command mount e:\\ /etc, mount e:/ /etc or mount e: /etc, only the drive letter and the colon (e:) is recorded in the registry. This causes setup.exe to crash when it tries to copy files (e.g. to /etc/postinstall). Manually editing the registry, adding a backslash after the colon, solves the problem. I suggest that setup.exe assume that driveletter: means driveletter:\ in the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 and possibly HKEY_CURRENT_USER\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2). Setup.exe demands that the cygwin root directory, which is asked for on its third screen, is absolute, i.e. begins with driveletter:\, so that's not a problem. Regards, Magnus Holmgren -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
