This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: strange crashes on invocation


On Sat, Sep 25, 2010 at 08:46:25PM +0200, Corinna Vinschen wrote:
>On Sep 24 18:36, Corinna Vinschen wrote:
>> On Sep 24 10:07, Christopher Faylor wrote:
>> > On Fri, Sep 24, 2010 at 12:48:50PM +0200, Corinna Vinschen wrote:
>> > >What I'd like to propose is to minimize autoloading to the entry points
>> > >which are not available on all OSes.  Other than that, we should link
>> > >cygwin against all used system DLLs so it can profit from the fixed
>> > >DLL addresses and the potential speed advantage the DLL sharing grants.
>> > 
>> > I don't see how fork enters into this since Cygwin doesn't have any
>> > visibility into the data in a system dll.  It shouldn't matter where one
>> > of these guys is loaded.
>> 
>> Yes, in theory.  I was just thinking that this somehow looks like a
>> situation which appears to be similar to what happens in fork if a DLL
>> can't be loaded at the right spot.  I can't imagine why loading
>> ws2_32.dll works most of the time but sometimes fails for no apparent
>> reason.  Of course there are still three possible other solutions:
>> 
>>   - Bug in ws2_32.dll
>>   - Bug in cygwin1.dll
>>   - Bug in application
>> 
>> > But, coincidentally enough, I was thinking the
>> > same thing about dropping the dynamic linking.  It is less important now
>> > that we no longer support Windows 9x.
>> > 
>> > The other motivation for the autoload stuff was supposed to be reducing
>> > the runtime link cost of resolving symbols that would never be used.  It
>> > would be interesting to see if there is any noticeable performance change.
>> > I could see it either getting faster or slower.
>> 
>> I'll do some speed comparisions over the weekend.
>
>The results are terrible.  There are three system libs which have no
>visible impact when being linked against (ws2_32, secur32, rpcrt4).  The
>others have a performance *hit* from 2.5% (user32), up to 25% (iphlpapi,
>shell32).  In no way do the results support the point I was trying to
>make.  Autoloading rulez.

Wow.  I'm quite surprised.  I didn't think it would make any discernible
difference.  I only implemented this stuff on a whim to clean up all of
the "if (this_is_windows_version_blah) ... else ..." stuff.  I thought it
might have a positive performance impact but I never actually checked.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]