I added a check in the .NET bootstrap code to reuse the existing DLL and PDB file if its up-to-date. That should have a big impact on startup time.

However its still not on par with Java - I think our Zip library is the other big culprit since its written in managed code. I'd like to try and find an unmanaged implementation and see how much that helps.

You should probably check not only the pod's timestamp, but all its dependencies too. For example if sys changes, then everything should be considered out of date (assuming you aren't already doing this).

Thats probably the safest thing to do - though really in that case you probably should have recompiled all the dependent pods anyways to make sure everything is up-to-date, which implicitly handles that case.

We probably do a need a mechanism to force a cleanup of those DLL/PDBs. Not sure if thats a runtime flag, or if a build full is sufficient?

It isn't a requirement to recompile pods when a dependent pod changes - that is the nice thing that Java fixed about C++. And the beauty of mixins is that you can add new methods to an "interface" and not break existing code (as long as you provide an implementation). However the runtime does need to emit new bytecode/IL with the appropriate router methods.

If if the "clean" build target nukes them that seems fine to me.

Fixed BuildPod::clean to clean up dll/pdb files.

I went back and fixed this behavior, a DLL/PDB is only reused if that pod and all its dependencies are up-to-date. So rebuilding sys will force all pods to be re-emitted. The clean target still cleans up the DLL/PDB for that pod.