I have a feature request: When your project uses some asmdefs but there are some CS files outside of an asmdef, unity should give a warning and it should mention the file that’s outside of an asmdef.
e.g., Warning: Assets/Scripts/Foo.cs is not in an asmdef. Your whole project will compile on every change which will increase compile times.
Having this warning would imply that the user is doing something wrong when in fact it’s absolutely fine to work this way, there is no guarantee it will be slower and the difference could be negligible once you factor in the assembly reload time.
If the user is anything like me they will just ignore the warnings, thats what they’re for, right 
If you want to do this in your own project you could write an editor script to check. Iterate through the scripts in the project(use AssetDatabase) and check them with CompilationPipeline.
e.g Unity - Scripting API: Compilation.CompilationPipeline.GetAssemblyNameFromScriptPath
You could do this, but I can’t imagine a scenario where I’d want to use asmdefs for half my code.
That sounds like a great compromise. I’d just warn if GetAssemblyNameFromScriptPath returned null, right?
Yes, that should work.
Most projects are like this now since all our packages use asmdefs.
Sorry, but don’t the docs imply the opposite? In fact they say:
Note: Although not strictly required, Unity recommends that whenever you use Assembly Definitions in a project, you do so for all of the code in your project. Otherwise, when you change scripts in one of the predefined assemblies, Unity must still recompile all the code in your project, since the predefined assemblies automatically depend upon any assemblies you create using an Assembly Definition.
At what point will “asmdefs everywhere” benefit me? I know the answer is going to be, “it depends,” but there must be some heuristic out there I can use to consider “asmdefs everywhere.” e.g., When there were 500 .cs files in a project, asmdefs helped. When there were 250, it didn’t make a difference.
Every time I import a new library, I spend 30-60 minutes figuring how to create asmdefs for it. Is this usually a waste of time or usually a good idea?
It really depends on the project. It’s true that changing files not in an asmdef will trigger compilation for all however In a simple project this time is normally very small and it’s the assembly reload that takes the longest part of the process. Assembly reload can actually get longer with more asmdefs so there’s a sweet spot where that time is negated by the reduced compilation time. If you are putting every library you have into its own asmdef then that may make things slower (if there’s a lot), it’s usually better to put all the library code into a single asmdef, this is one of the reasons we added asmrefs in 2019.2.
As a project gets bigger then it can make a difference so big projects should certainly use it. We are working on some better profiling tools to help setup asmdefs which should make this easier to see in the future.
Thanks for the information! I’m glad to hear the tools are coming, but is there anything I can do to check performance today? I’ve literally been using my cell phone’s stopwatch to check for compile times. I think the editor log provides some useful information, but I’m not sure if it breaks it down enough to know if asmdefs are helping or hurting.
You can do something like this https://gist.github.com/karljj1/9c6cce803096b5cd4511cf0819ff517b