So, My Time at Portia was successfully funded, and Alpha 3.0 is coming out next week. :yay:
/me winks to Dinosawer
I was reviewing some bugs from Pathea's Forums and reviewing the output.txt log file and found these interesting nuggets.
It uses Unity, so that might help?
Code: Select all
Unloading 11 unused Assets to reduce memory usage. Loaded Objects now: 5983. Total: 0.973503 ms (FindLiveObjects: 0.161755 ms CreateObjectMapping: 0.109367 ms MarkObjects: 0.584372 ms DeleteObjects: 0.117468 ms)
Now, my question is, in relation to
Code: Select all
Unloading 33722 unused Assets to reduce memory usage. Loaded Objects now: 113007. Total: 315.695862 ms (FindLiveObjects: 6.306307 ms CreateObjectMapping: 7.529600 ms MarkObjects: 197.540573 ms DeleteObjects: 104.319115 ms)
Sorry for the long-winded prose, but thanks for getting this farJoshParnell wrote: ↑Fri Jun 09, 2017 10:23 amRe GC: it definitely makes a certain percentage of it irrelevant. The higher that percentage, the higher the perf. My goal is 100%, so that we can turn off the GC entirely. That's actually a reasonable goal I believe, considering that we've already established how much of a difference having the data live in C makes. I will (and have already to some extent) make it as easy as possible for people to define new datatypes that can live on the C side, so that scripts can still have their own helper data and such without unknowingly invoking GC.
But even if we don't manage to do away with it entirely, keeping most of the data out of the Lua side makes GC way faster. GC times are roughly proportional to total Lua-allocated memory, so with 90% of the memory being managed by C, 90% of the GC's work goes away. It will be good
Can anyone explain in numbers what LT does with it's new GC?
With a rough comparison of LT and the information above, how does LT perform?
Like for example, the recent asteroid field?
Thanks for listening