From: ian AT cygnus DOT com (Ian Lance Taylor) Subject: Re: Optimizing memset/memcpy/strcpy/etc. 16 Feb 1998 21:09:49 -0800 Message-ID: <199802170509.AAA21136.cygnus.cygwin32.developers@subrogation.cygnus.com> References: Reply-To: cygwin32-developers AT cygnus DOT com To: cgf AT bbc DOT com (Christopher Faylor) Cc: cygwin32-developers AT cygnus DOT com From: cgf AT bbc DOT com (Christopher Faylor) Date: Tue, 17 Feb 1998 04:57:59 GMT I tried that yesterday. I pulled over the assembly versions of various commonly used routines from glibc into a separate 'memory.c' file and rebuilt Cygwin32. I was disappointed to notice no noticeable speed improvement. It's hard to believe, but I really didn't see any difference in doing things like compiling a file in winsup. My offhand guess would be that gcc on cygwin32 spends no more than, say, 2% of its time in these routines, so even pushing their total time to zero, which is impossible, would speed compilations up no more than 2%. Of course, that's just a guess. What we really need is a profiler. I think somebody at Cygnus is working on a profiler, but I have no idea how it is going. I guess that means that the most obvious speed improvement will probably come from optimizing the loading of dlls (somehow), like Sergey has suggested in the past. Some of the posts on the gnu-win32 list have implied that Windows always relocates DLLs if they have relocation information. I would hope that that is not true--if the DLL is loaded at the image address, it should not be relocated. Does anybody know exactly what Windows does? Perhaps there is something incorrect about the DLLs which dlltool generates, which is leading Windows to always relocate them. Or perhaps the messages on the mailing list have been wrong. Ian