[Optimization] Speculatively not calling invariant on class objects

[Iain Buclaw via Digitalmars-d]

On 13 August 2015 at 19:12, Steven Schveighoffer via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On 8/12/15 8:22 AM, Iain Buclaw wrote:
>
>> This post got me thinking:
>> http://forum.dlang.org/post/mpo71n$22ma$1@digitalmars.com
>>
>> We know at compile time for a given object whether or not there are any
>> invariants, lack of any polymorphism, along with disallowing invariants
>> in interfaces means that for the given:
>>
>>    class NoInvariants { }
>>    NoInvariants obj;
>>    assert(obj);
>>
>> It's only a case of checking each base class for any invariant
>> functions, and if none are found, then we can make an (almost)
>> reasonable assumption that calling _d_invariant will result in nothing
>> but wasted cycles.
>>
>> However, these can't be omitted completely at compile-time given that we
>> can't guarantee if there are any up-cast classes that have an invariant.
>>
>> But we should be able to speculatively test at runtime whether or not a
>> call to _d_invariant may be required by doing a simple pointer test on
>> the classinfo.
>>
>
> My thought was that you could just set the default invariant pointer to
> null. Then when you load the invariant function to call, if it's null,
> don't call it.
>
>
That is what's done at compile time with structs.



> You could probably get rid of calls to _d_invariant by just calling the
> invariant directly, no?
>
> -Steve
>

Not with classes, because you need to walk over all interfaces in the
vtable, which more likely than not is unknown at compile-time.

Regards
Iain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150813/3eb791e9/attachment.html>