[Optimization] Speculatively not calling invariant on class objects

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Thu Aug 13 10:12:37 PDT 2015


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.

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

-Steve


More information about the Digitalmars-d mailing list