httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: Modifying Win32 default optimizations?
Date Wed, 11 May 2005 15:24:21 GMT
VC.NET 2005 (still in Beta 5) has much more optimizations (global nes at 
link time).
Maybe it would be better to go directly to it, no ?

----- Original Message ----- 
From: "Branko ─îibej" <>
To: "William A. Rowe, Jr." <>
Cc: <>; "Tomcat Developers List" 
<>; <>
Sent: Wednesday, May 11, 2005 3:46 PM
Subject: Re: Modifying Win32 default optimizations?

> William A. Rowe, Jr. wrote:
>>I'd like to modify the Win32 build projects (of mod_jk, and
>>httpd 1.3/2.0/2.1-dev, along with apr);
>>The /O2 optimization option is extremely agressive, unfortunately it 
>>produces less than ideal crash traceback information.  That is due to the 
>>(implicit) /Oy flag, which omits respecible stack
>>framing.  I'd like to change this to /O2 /Oy- to disable this
>>optimization; processing will be unmeasurably slower, but far
>>more useful when crashes do occur.
> Well, "unmeasurably" is obviously wrong :)
> But yes, I don't think an extra cycle per non-inlined function call would 
> show up all that much.
>>The /O2 optimization also simplifies the stack frame checking
>>for many functions.  The /Gs0 option would restore full frame
>>checks, to ensure we don't overflow the stack in the processing
>>of any function.  With FirstBill's (wise) choice to reduce the
>>size of our default stack frames within httpd, it seems wise to
>>be extra diligent.  However, MS's docs state that /O2 implies
>>/Gs - and I can't determine if that is /Gs0 (implied) or some
>>other behavior.  Thoughts from someone with more experience playing in 
>>stack probes would be appreciated.
> /Gs0 is a bad idea, IMHO, because it only makes sense if you write your 
> own stack probe routine. The default /Gs will probe a page at a time, 
> which works well with NT's virtual memory manager, and still makes the 
> stack grow enough.
>>All in all - comments?
> How about moving away from MSVC 6 to (say) VC.Net 2003, while we're at it? 
> It's time, to say the least.
> -- Brane

View raw message