[dmd-internals] changeset 455

[Steve Schveighoffer]

----- Original Message ----
> From: Brad Roberts <braddr at puremagic.com>
> I fully agree 
> that with D that it's unlikely that I'd leave unit tests 
> turned on in 
> production builds -- but if the tests are fast enough to 
> leave in, no real 
> harm either.  Keep in mind, they don't affect anything 
> beyond the cost 
> of app startup, or 
> shouldn't.

But we should not try to optimize unittests, they are not there for performance, they are there for diagnostics.  Make them as comprehensive and useful as possible, performance be damned.

My first point should explain why you should never leave them in -- they don't depend on anything but hard-coded values.  Therefore, they are almost entirely deterministic (you could argue that unit testing could potentially open files or something, but that is unlikely), and running them more than once is a complete waste of CPU cycles.

But I meant that when unittests were disabled, the assert handler linked would be the faster variety, and when unittests were enabled, the assert handler would be the comprehensive unittesty variety.  The object files would be identical, it's just what assert function do you link with.  I don't know if it's possible, which is why I asked.

If that's not possible, we still have another option.

An assert translates roughly to this:

if(!condition) {throwAnError();}

We all agree that when throwAnError is called, performance is out the window (nobody but the runtime should be catching asserts, and we should expect the program to exit soon after since it's in an invalid state).  Why can't the check for whether we're in unittest mode be inside that function/block as Andrei pointed out?  My larger point is simply that we should not consider performance problems to be important during unit testing, asserts can be slow, because unittests do not need to be as fast as possible.

-Steve