Hi, thanks for posting.

The problem with these kind of guidelines is that there are so many variables involved.

For example, a large project with 100,000 lines may work reasonably well if it's using the NCrunch MSTest adapter set to static analysis (which is pretty fast) and there is a minimal number of attributes defined on the methods.

Conversely, you might find a smaller project with 50,000 lines is a struggle if it's using many advanced test framework features under dynamic analysis, with lots of small methods.

Then of course, there is the big variable that is hardware performance.

We're working on building some tools in-house to help us identify and address scalability problems that are associated with some of the more extreme scenarios (such as a huge volume of tests vs a huge volume of code, etc). The key issue here is that there a multiple dimensions in which scaling needs to be addressed.

For the time being though, I think the best way to know when your project is too big is to just look at the times in the performance view and decide when you're waiting too long.