A big number of patterns in project.json will increase the file globbing time dramatically.

[akoeplinger]

Repro code: https://github.com/akoeplinger/dnx-globbing-loop

Tested with 1.0.0-beta5-11469 coreclr x86 on Windows 8.1

Repro steps:

1. Run dnu restore
2. Go to src\sample\TestAppWrapper
3. Run dnx . run

Watching via procmon shows it loops endlessley in the directories:

/cc @davidfowl @troydai

[troydai]

Looks like I can repo it. I'm at the crime scene.

[akoeplinger]

In case you missed it on JabbR: moving the relative paths from compile into compileFiles fixed the "loop" as you suspected.

[troydai]

@akoeplinger thanks for the confirmation!

Here's a brief explanation to the issue:

Every string listed in compile is treated as a pattern no matter whether if contains wildcard. Therefore when a big number of patterns exist the matcher will process every one at each level of the search path. It is not a infinite loop but a extremely long process.

There is solutions to it:

Short-termly, for path reference single files listed them in compileFiles can reduce the load on file globbing.
And in the file globbing, optimization can be done so that one directory won't be visited repeatedly even it is matched in multiple patterns.

[troydai]

/cc @lodejard @loudej

[akoeplinger]

Yep, thanks for the explanation, sounds good!

[davidfowl]

@troydai Can we use the new diagnostics system to warn/error when absolute paths are used in compile?

[troydai]

@davidfowl two pivots about sending warning here:

1. The files globbing is a black box, we didn't leave API to return a non-fatal error information. Of course we can change the interface to allow that.
2. What's the threshold of "too many paths" since this is not a simple black and white case, we need to find a point value beyond which we return warning.

I'm working on one solution to prevent file globbing from repeatedly look into same folder, hopefully it can mitigate the issue.

[troydai]

Fixed.