I was reading a blog post here: http://3d.benjamin-thaut.de/?p=20 which mentions:

"Calls to the druntime invariant handler are emitted in release build also and there is no way to turn them off. Even if the class does not have any invariants the invariant handler will always be called, walk the class hirarchy and generate multiple cache misses without actually doing anything."

I was curious if this was still true today (the post was written 3 years ago in Sept 2012).

Thanks!

On 12/5/15 6:06 PM, Andrew LaChance wrote:
> I was reading a blog post here: http://3d.benjamin-thaut.de/?p=20 which
> mentions:
>
> "Calls to the druntime invariant handler are emitted in release build
> also and there is no way to turn them off. Even if the class does not
> have any invariants the invariant handler will always be called, walk
> the class hirarchy and generate multiple cache misses without actually
> doing anything."
>
> I was curious if this was still true today (the post was written 3 years
> ago in Sept 2012).
>
> Thanks!

I don't remember that the invariant was ever called in release mode. But maybe I'm not understanding the statement.

-Steve

On Sat, 05 Dec 2015 23:06:22 +0000, Andrew LaChance wrote:

> I was reading a blog post here: http://3d.benjamin-thaut.de/?p=20 which mentions:
> 
> "Calls to the druntime invariant handler are emitted in release build also and there is no way to turn them off. Even if the class does not have any invariants the invariant handler will always be called, walk the class hirarchy and generate multiple cache misses without actually doing anything."
> 
> I was curious if this was still true today (the post was written 3 years
> ago in Sept 2012).
> 
> Thanks!

It's not true today, as you can test yourself:

class Foo {
	invariant {
		assert(false);
	}

	string str() {
		return this.toString;
	}
}

void main() {
	import std.stdio;
	writeln(new Foo().str);
}

$ rdmd invar.d
core.exception.AssertError@invar.d(3): Assertion failure
$ rdmd -release invar.d
invar.Foo

I've never used a release build of anything. Bounds checking isn't that expensive.

On 12/5/15 6:54 PM, Chris Wright wrote:

> I've never used a release build of anything. Bounds checking isn't that
> expensive.
>

void main()
{
    int[] arr = new int[10];
    assert(arr.capacity == 1000); // obviously wrong
    arr[10] = 5;
}

dmd -release -boundscheck=on testboundscheck.d

./testboundscheck

core.exception.RangeError@testboundscheck.d(5): Range violation
----------------
4   testboundscheck                     0x000000010df8454d _d_arraybounds + 97
5   testboundscheck                     0x000000010df77da6 testboundscheck.__array + 38
6   testboundscheck                     0x000000010df77d71 _Dmain + 49
7   testboundscheck                     0x000000010df94e83 D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv + 39
8   testboundscheck                     0x000000010df94dbb void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) + 55
9   testboundscheck                     0x000000010df94e28 void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() + 44
10  testboundscheck                     0x000000010df94dbb void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) + 55
11  testboundscheck                     0x000000010df94d0d _d_run_main + 497
12  testboundscheck                     0x000000010df77e0f main + 15
13  libdyld.dylib                       0x00007fff928d15c8 start + 0
14  ???                                 0x0000000000000000 0x0 + 0

-Steve

On Saturday, 5 December 2015 at 23:27:31 UTC, Steven Schveighoffer wrote:
> On 12/5/15 6:06 PM, Andrew LaChance wrote:
>> I was reading a blog post here: http://3d.benjamin-thaut.de/?p=20 which
>> mentions:
>>
>> "Calls to the druntime invariant handler are emitted in release build
>> also and there is no way to turn them off. Even if the class does not
>> have any invariants the invariant handler will always be called, walk
>> the class hirarchy and generate multiple cache misses without actually
>> doing anything."
>>
>> I was curious if this was still true today (the post was written 3 years
>> ago in Sept 2012).
>>
>> Thanks!
>
> I don't remember that the invariant was ever called in release mode. But maybe I'm not understanding the statement.
>
> -Steve

I think what he was saying was that even in release mode, the druntime would keep the invariant "subsystem," but just wouldn't call the invariant handlers.  So even in release mode, the code to get a list of all handlers would happen, they just wouldn't be invoked.  Rather than completely ripping out the invariant system.

On 12/6/15 6:01 PM, Andrew LaChance wrote:
> On Saturday, 5 December 2015 at 23:27:31 UTC, Steven Schveighoffer wrote:
>> On 12/5/15 6:06 PM, Andrew LaChance wrote:
>>> I was reading a blog post here: http://3d.benjamin-thaut.de/?p=20 which
>>> mentions:
>>>
>>> "Calls to the druntime invariant handler are emitted in release build
>>> also and there is no way to turn them off. Even if the class does not
>>> have any invariants the invariant handler will always be called, walk
>>> the class hirarchy and generate multiple cache misses without actually
>>> doing anything."
>>>
>>> I was curious if this was still true today (the post was written 3 years
>>> ago in Sept 2012).
>>>
>>> Thanks!
>>
>> I don't remember that the invariant was ever called in release mode.
>> But maybe I'm not understanding the statement.
>
> I think what he was saying was that even in release mode, the druntime
> would keep the invariant "subsystem," but just wouldn't call the
> invariant handlers.  So even in release mode, the code to get a list of
> all handlers would happen, they just wouldn't be invoked.  Rather than
> completely ripping out the invariant system.

I don't think that's true. The invariant is called as part of function execution.

Using obj2asm, the code emitted for an empty class function is vastly larger without -release.

-Steve