Extremely long compile times

HI all, does anyone have very long assembly time? My project is about 1.2 mb, the dlls compile in visual studio in a matter of seconds but then my device specific generation will take about 15 minutes. When I’m making small changes, this can be very tedious. When looking at task manager, it appears to be pegging 1 thread so I may be limited in that regard, but i have 12 so I’d like to see if there’s a way to utilize more of my cores or something, or see if there’s a way to only generate new assemblies for the parts I’m changing, etc. I just need to lower the amount of time I’m spending sitting at my desk twiddling my thumbs waiting for it to finish.

That’s surprising. I have a project that uses virtually every GHI TinyCLR assembly, plus a ton of my own code (full metric ton) and results in a 3.8 mb PE file and it takes perhaps 60 seconds at worst not including flashing 800 sectors (which includes 5mb of resources).

There are a lot of fileops involved. Are you on an SSD or spinning drive? In my case, SSD.


NVMe SSD, so I guarantee that isn’t the bottleneck here. I think the codebase is between 60-75000 lines of code, which isn’t huge, but I’ve starting implementing a lot of my own custom events and threading into it after our other engineer left that did almost none of that and I’ve noticed that my compile times have increased drastically. It still took about 5 minutes for his code base when i first inherited it, but now it’s ballooning pretty fast. I’m wondering if there’s a setting I’m missing.

Well, that is a pretty big project, but even if I extrapolate from some of my projects, it is worse than linearly worse based on lines of code. Got enough memory? (>32Gb?) Is all that code factored across assemblies? I can’t claim to know whether that will help or hurt, but if it’s all in one assembly, it might be something to try because I’m certain that the working set cost and fileio cost is much worse for large single assemblies, not to mention what you lose from not being able to do incremental compiles for small changes.

In .netMF there was something, somewhere that precluded 64K was the upper limit for assemblies.
However, after running into such a road-block, as I assume you are seeing, is the number of methods() or function()s within an assembly is the limiting factor.

Fix was to add >> build a new assembly, with such methods() that will not create cross-references.
Yes a bitch…but such works.?

Really, in the end, one discovers a deeper meaning of the code ones written…weird ehhh.!

@mcalsyn -

Am still on .netMF, but am moving to tinyCLR OS, new board, new SOM, etc.
The only reason we have yet to jump is mainly time, i.e. pipe-line cannot be empty.

Is there absolutely anything…anything, using adage of ‘full metric ton’ as to code, why one should re-consider.?

The G120 provides all services…really required, however there is always stuff on the wish-list.

Given circumstances, would or would you not switch?..I value your opinion.!

No, it’s broken into 17 assemblies. my PC isn’t like a rendering machine, but it isn’t a slouch either (i7-8850h, 16GB of ram) and should easily handle this job. When i took my work home and did some development on my gaming PC, i noticed by build times were only 2-3 minutes so it may just be a brute force issue.

Do you know if there’s a way I can turn on messages or something to determine which assembly is taking so long? it just says “generating assemblies” and changing things in my configuration manager doesn’t affect this step at all.

The fact that the build time is so much faster at home definitely indicates something environmental, and not something in the layout of your code. I think I would spend more time looking at environmental issues like available (not total) memory and CPU on the two machines and the footprint (working set, io counts, and percentage of total machine load). The fact that two machines are behaving differently kind of takes the code itself off the table.

There is a metasomething.exe tool that does that phase. I think that in order to debug that we’d have to take a look at the source code for that tool in the netmf SDK and see if there are debug switches you can turn on (or hack in).

I mean i’m still bothered by the fact that yours take a minute at worst and my best case scenario is still significantly longer (Are you willing to share the specs of your dev machine?) . I’ll have to check it again as well, I haven’t worked from home since the early stages of me taking over the project and I’ve added a lot since then. I’ll update the repo at home and run a test compile to see what happens.

Even when pegged, my PC seems to be chugging along at full power, it’s not thermally throttling or anything, there’s 4 GB of free memory that isn’t being touched - and my SSD looks like this:

The resources are there, it just doesn’t seem to be taking advantage of them at all.

There are a lot of good reasons to move to TinyCLR. For one thing, it is where all the GHI effort is going. The tooling is better; the libraries are better (and open source), and by better, I mean more aligned with netstandard, UWP, and IoT Core and richer functionality. The security is far better. Cloud support is better. TLS/SSL is available for secure networking. The underlying firmware has paid more attention to performance. It’s just all-around more modern and performant.

It may be that you don’t need those runtime things, in which case all you would be winning is better support, and better tooling, but that still may be enough.

Now, I am not a GHI employee. I work for Microsoft in a completely different tech area. I do contribute a bunch to the GHI Libraries. But my point is that I am not getting paid to say all this, but my own experience has been a lot smoother in TinyCLR 2.1 than in netmf.

In the end, you will pay some sort of effort in moving to TinyCLR for sure, and you have to decide if the upside balances out against the cost over the lifetime of your product, which will depend on a lot of use-case and business factors that only you know.


While my code is non-trivial, it is still less than half the size you are talking about here. But even if I extrapolate, your perf is way worse than linearly worse.

Here are my machine specs:

I have three drives:
1Tb Samsung Evo SSD NVMe PCIe boot drive
1Tb 7200RPM drive archival
2Tb Samsunc Evo SSD NVMe PCIe projects/code/etc

GPU: Nvidia 1080Ti

I’m beginning to think it’s single thread performance based. The 8700K is a little faster than the Ryzen 5 in my home machine in single thread performance and the ryzen will smoke my work laptop, but I’m definitely annoyed that my work laptop is THAT much worse. it’s a pretty potent machine that I was given to run Solidworks back when I was still in design.

Task manager confirms that it only uses a single thread anyway, so i may just be stuck until GHI is able to implement multicore compilation.

1 Like

GPU: Nvidia 1080Ti - are you gamer :smiley:

Gamer? Not that you know of.

If I was a SERIOUS gamer, I would have an RTX3080Ti, but those are USD $3K and up because of the dang coin miners.


Thanks for response and affirmation of tinyCLR OS.
Going a different route really was not even considered.
Kinda just waiting for solidification and assurance of such.

New board design mostly baked.
Not ready for production yet…but will be soon.

For all on this forum…what GHI does is not kiddy stuff.
Such works reliably in all environments where the human form exists…empirical statement.


@Gus_Issa Is there a possibilty that more verbosity could be added to the deployment step? I’m specifically interested in seeing when the cross compiler is done with each library so I can figure out which of my assemblies is taking so long. They’re all reliant on one another so I can’t just disable them one at a time to figure out which one is the culprit.

Not sure since this is visual studio compiling, not us deploying.

If you want share your project with us to investigate further.

This step here?

Yeah, I’d be willing to let you guys take a crack at it. Let me know what the proper channel is and i can get you a copy of our source code.

Simply email support@ghi… and put my name in it please. Please share a download link instead of zip file if you can

1 Like