Re: [Openexr-devel] Pulling my hair out: switching projecttoVS2008breaks OpenEXR :(

[Chris Cox]

I have some nice benchmarks that put the penalty at 200 to 3000 percent.
(one version of it was recently posted to the boost mailing list, I hope to
have it with the rest of my open source benchmarks soon).

I guess actually using vector is an "unusual" case for them.

No, their overhead is too high even for debug builds.  Of course, that could
be because their optimizer doesn't do the optimizations that would make the
bounds checking faster.

Chris



On 10/27/08 5:08 PM, "James Burgess" <address@hidden> wrote:

> They have consistently maintained that the performance hit is minimal
> except for "unusual cases" what ever that means. If you look through
> the msdn forums you'll see that the engineers involved are always very
> interested in specific test cases that perform poorly which they do
> admit exist. If you have one I would suggest you post it there.
> 
> I'm curious, do you have timings to illustrate your frustration?
> 
> The debug mode iterator checks do have a significant performance
> overheard but I think everyone would agree that's ok.
> 
> 
> 
> 
> 
> On Oct 27, 2008, at 4:50 PM, Borislav Trifonov wrote:
> 
>> I set it to 0 across all my libraries and it's all good now.  How
>> Microsoft can have this checking enabled in Release build by default
>> is beyond me...
>> 
>> 
>> 
>> ----- Original Message -----
>> From: Chris Cox <address@hidden>
>> Date: Monday, October 27, 2008 2:09 pm
>> Subject: Re: [Openexr-devel] Pulling my hair out: switching
>> projecttoVS2008breaks OpenEXR :(
>> To: address@hidden
>> 
>>> You have to specify _SECURE_SCL=0 in every module of your
>>> project, including
>>> static and dynamic libraries.   Otherwise the vector
>>> data structure changes
>>> size and the module with the larger size will barf on memory.
>>> 
>>> You can thank Microsoft for the fragile implementation and the
>>> huge slowdown
>>> if you fail to set it to zero.  (some of our applications
>>> need it set to
>>> zero even for debug builds, because the added overhead is very,
>>> very high)
>>> 
>>> Chris
>>> 
>>> 
>>> 
>>> On 10/24/08 10:04 PM, "Bob Friesenhahn"
>>> <address@hidden>wrote:
>>> 
>>>> On Sat, 25 Oct 2008, address@hidden wrote:
>>>> 
>>>>> It turns out that having _SECURE_SCL=0 defined in my project
>>> (not even in the
>>>>> OpenEXR project) is what OpenEXR couldn't handle--for
>>> whatever reason I
>>>>> cannot imagine. What's going on here? I need this setting as
>>> otherwise the
>>>>> slowdown from the bounds checking the Visual Studio nanny
>>> does on STL vectors
>>>>> in opposition to the standard is unacceptable.
>>>> 
>>>> Google says:
>>>> 
>>>> 
>>> http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedbac
>>> kI 
>>> D=352481
>>>> 
>>>> "Specifing a project with #define SECURE_SCL 0 which uses
>>>> std::vector<..> may result into a case in which the application
>>>> overwrites memory."
>>>> 
>>>> Bob
>>>> ======================================
>>>> Bob Friesenhahn
>>>> address@hidden,
>>> http://www.simplesystems.org/users/bfriesen/> GraphicsMagick
>>> Maintainer,    http://www.GraphicsMagick.org/
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Openexr-devel mailing list
>>>> address@hidden
>>>> http://lists.nongnu.org/mailman/listinfo/openexr-devel
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Openexr-devel mailing list
>>> address@hidden
>>> http://lists.nongnu.org/mailman/listinfo/openexr-devel
>>> _______________________________________________
>> Openexr-devel mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/openexr-devel
> 
> 
> 
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/openexr-devel