Bigger Is Not Always Better: Builds Are Faster with Smaller Packages

One trend over the past few years is that the projects I've been working on tend to get bigger and more complicated. Bigger projects come with new challenges. Among these are the fact that it's much more difficult to keep the entire project in one's head, the need to synchronize with more developers because team sizes grow, a higher risk of having to re-write code because of poorly understood requirements or because some requirements change, and many more.

This is a companion discussion topic for the original entry at

Thanks for this thorough analysis, Tudor. EDA compiler turnaround times are a real pain. I will watch out for the points you mentioned.

Related to this, if you have a large package containing a couple of hundred tests, you can shorten compile time for debug runs if you only compile the one test at hand. We once did this by using a macro to selectively include a test in the package.

Selective includes become more complicated if you have tests that rely on other tests: test_a, test_a_with_x_constraints, test_a_with_x_constraints_and_y_constraints. To be able to run the most specialized test, you’d need to compile all there.

Hi Tudor,

What is your take on packages improving simulation performance. I don’t think it is true, but I keep hearing about it, but do not see any data to back it up.


Sounds strange. I’d expect similar performance, regardless of how the code is structure compile-wise.