evaluate the sprite dimensions in the generator script instead of relying on nmlc's sloooow template evaluation. this speeds up compilation by 30% (3min->2min), but doesn't seem to help with #3803, memory footprint actually seemed larger, even though this clearly reduces code complexity
- Assignee changed from 0 to compiler
Did NML really run out of memory? Definitely server-side, but it's probably still the time to take another look at splitting this up...
i don't even get it... nothing has changed code-wise.
i just watched a build locally, and it peaked around 31% (of 4GB).
i have an idea that i wanted to try to reduce compile time, maybe it works to reduce memory footprint as well, but i think it's NML's fault, it should really not explode like this...
I rised memory limits of devzone significantely (+50% to 6 GB), I am not sure, if it was wise for the system, but cets builds again...
- Status changed from New to Closed
- Assignee deleted (
Also available in: Atom