Which scenario below would compile faster?
Two projects inside of a solution. Each project has 5 classes.
One project inside of a solution. The project has 10 classes (the combination of the two projects in scenario a).
Basically, I'm trying to see if having 2 projects would affect the compile time in a solution.
I would say yes, it does have an impact to have separate projects. A project is a standalone output and the linking would be different. It would have to also find dependencies from the references in the other project. The only way to find out is to try.
Having more projects means there is more work to do and hence will almost certainly take more time. Besides the actual compilation at least the following actions would have to be duplicated
The compiler takes each class through references. The bottom layer (no internal project references) has to be compiled first, then the layers that reference other internal projects, and so on. Therefore, yes, the compile time will be slightly increased due to the fact that the compiler has to sort the references and create multiple binaries.
On the other hand, most large projects SHOULD be separated into multiple projects and namespaces for ease of readability and navigation. It really depends on what you're doing, but you could potantially put 1000 classes in a single file, or multiple files, or multiple files in multiple projects. The amount of time (minimal) saved in the compile time won't compare to the time wasted looking for stuff in a poorly laid out solution.
With a solution of 2 projects with 5 classes, the compile time will be milliseconds different from a single project of 10 classes. The linking and referencing is the only real increase you'll see, and that is minimal.
EDIT: On another note, if you have a project large enough that you're noticing a real difference in compile time, you should probably be considering implementing some sort of continuous integration (see: http://en.wikipedia.org/wiki/Continuous%5Fintegration) environment, which will keep a current build ready for you, as well as letting you know if something's broken.
I would say yes, but I think the difference in time would be miniscule unless the files are very large (10k lines was when it started slowing down for me)
Note: the file I compiled with 10k lines was only because I was bored, I never actually used it for production, it was a lot of code I was migrating from previous projects into one.
I have a large project that I'm in the process of splitting into smaller projects, and I noticed that compile time takes just a little longer than before. So yes, it will increase compile time, but in my case it was by a few seconds. I can imagine that the change would be far greater the larger the projects in question.
You want us to tell you which is faster: 10 classes in one project, or 5 classes in each of two projects.
Can't you tell the difference yourself?
If you can tell the difference, then you can pick the one that's faster.
If you can't tell the difference, why does it matter which is faster? Pick the one that makes more sense to you.
There's something wrong with your question, though. The time to compile 10 classes of any reasonable size is minimal, so trying to optimize it is a waste of your energy. What's your real question?
More projects takes slightly longer. The type of project can make a big difference. Install projects take a long time to compile because of all the zipping and such that happens, and (for me anyway) SQL Report projects can take a long time.
In my experience doing .Net development, it depends on whether you have the multi-threaded compile enabled or not.
VS has the ability to compile multiple projects in tandem on separate cores, so if you have a multicored system, it goes significantly faster with separate projects than one giant one.
Yes, in large C# solutions, having more projects makes compile time very noticeably longer (by many minutes). At least, that's my experience. However, I would add a caveat. I suspect that projects are compiled when it is not strictly unnecessary because C# is not all that smart about what it chooses to compile. So if most projects do not reference other projects much, it may not be such a problem. I can't tell for certain because the code I've worked on (legacy stuff, not mine, I hasten to add) that has this sort of problem is not loosely coupled from that POV.
Mind you, slow compilation is a feature of some languages (all the C-based ones, for example). Languages that can be compiled in a single pass (eg Pascal derivatives like Delphi), compile far quicker (10^6 LOC in seconds).
So there is a limit to how fast you can get anyway. It's mostly a hardware issue as compiling is very disk intensive (ie slow) for most languages (FLs can be an exception). Other threads here talk about ways to speed up VS compilation times, and the biggest improvement is always by getting a really quick HD, or better, a modern SSD.