Phobos Unittest (page 2)

On 9/4/21 7:43 AM, Johan wrote:

On Saturday, 4 September 2021 at 03:18:01 UTC, Paul Backus wrote:

On Saturday, 4 September 2021 at 00:09:37 UTC, H. S. Teoh wrote:

This is related to the bogonity of the current behaviour of -unittest, which compiles all unittests of all imported modules, even when you're compiling user code that has no interest in Phobos unittests.

Well, no; it compiles all unittests of all compiled modules, not all imported modules. So it does not actually include Phobos unittests.

[...]

As Steven Schveighoffer [pointed out][1], Phobos unittests are never included in user code, regardless of whether StdUnittest is used.

The "never" is false, https://d.godbolt.org/z/c4oeYM7rG

Unittests inside template code will be added to user code, unless the compiler has determined that the template is already instantiated in Phobos code (the "template culling" that the frontend does, whose behavior is not easily influenced by the programmer).

It's always included (or at least it was when I last looked at it), as -unittest implies some form of -allinst. There was some effort to fix this, but I can't remember if the outcome was that it was merged or not.

-Steve

$ objdump -dwr --no-show-raw-insn importstd.o |ddemangle | grep -oP 'std[\w.]+'|sort|uniq -c|sort -n|awk '$1 > 1' 28 std.uni.InversionList 28 std.uni.MultiArray 30 std.encoding.BOM 31 std.array.Appender 35 std.concurrency.List 35 std.concurrency.Message 38 std.uni.CowArray 44 std.variant.VariantN 56 std.typecons.Tuple 56 std.uni.BitPacked 66 std.uni.GcPolicy

September 05, 2021

Re: Phobos Unittest

Posted by Steven Schveighoffer
in reply to Per Nordlöw

Permalink

Steven Schveighoffer

Posted in reply to Per Nordlöw

Permalink

On 9/4/21 4:05 PM, Per Nordlöw wrote:

On Saturday, 4 September 2021 at 13:12:49 UTC, Steven Schveighoffer wrote:

Note that lexing and parsing is extremely quick, and I wouldn't focus on trying to trim this out, you won't get much performance out of that.

-Steve

For the record, a D file containing only import std; type checks via

time dmd import_std.d -o-

in 0.20s whereas

time dmd import_std.d -o-

in 0.45s on my ThreadRipper.

I doubt that's because of the parsing. I've gone down these kinds of rabbit holes. It's one of the reasons I tried to remove ALL version(unittest) blocks from phobos that import other modules. But you just can't remove them all. And any unittests inside templates are going to compile and get included, even if you don't instantiate anything. I also discovered that CTFE initializers run, even if you don't use the imported symbol, and even if you don't need type inference. Can't remember if that got fixed.

I think you would find you could probably attribute the 0.25s there to a few modules that do things when unittests are turned on.

According to https://github.com/dlang/dmd/blob/1ae5fee06ddd0599fb187595f8b0cebf8c840ebd/src/dmd/parse.d#L642-L683, if unittests aren't turned on, indeed the parser simplifies its parsing of the unittest. It skips over the unittest block, and doesn't allocate any AST nodes for it. But that difference I don't think is going to be the cause for a significant slowdown.

One can construct a test to check the parsing:

Generate a huge source file with 10,000 (or maybe more?) non-trivial unittests. You need enough to move the needle on parsing.
Import that file, and build the main file with and without the -unittest flag.
This should not actually compile the unittests, but just parse them.

Using phobos as a test case is rife with things that may be contributing besides the parser.

-Steve

Forums