Daggerfall Workshop Forums

Hi Nystul,

Nystul wrote: ↑Sun Feb 03, 2019 5:44 pm which build do you use?
which mod version do you use?

I did the test with the latest versions available at the time, so that must have been with 2.6.0.

I redid a test with the current dev build, and just Distant Terrain 2.6.0, simply riding horse in the desert, see logs in attachment.
GC takes less time, 40~45ms, maybe because unmoded resources are lighter. But GC is still triggered with each new map pixel.
Last one in the log is triggered by the closing of the "Escape" menu when I used it to exit the game, but this one is well identified (called from UserInterfaceWindow.CloseWindow() )

In unmodded DFU, UnloadUnusedAssets() is called when terrain is generated but only when initialising. So for load game or teleport or exit to outdoors. It should not be happening when moving from one map pixel to the next. To put this into perspective even with all of the optimisations that have been done, initial init of terrain from scratch takes at least a second, sometimes over 2 on my Ryzen 1600 system. So it's adding some ms to the time before the screen unfades and you can move.

This is different in this mod, where is called every map pixel transition. I assume Nystul did this for a reason, but I don't know what that is.

Hi Hazelnut,

Hazelnut wrote: ↑Sun Feb 03, 2019 9:25 pm This is different in this mod, where is called every map pixel transition. I assume Nystul did this for a reason, but I don't know what that is.

I came to the same conclusion; and now with all those optimizations 100ms hiccups start to matter...

UnloadUnusedAssets() is called on purpose - the reason is that many people complained that they get out of memory exceptions when using the mod and the reason was that loaded assets not being cleared was the issue. We could try again to get along without but I fear the cries of some people with low spec machines again
see this post: https://forums.dfworkshop.net/viewtopic ... 320#p14473

Since the time taken by UnloadUnusedAssets() seems almost constant for a given workingset (and not depend on the amount of free-able assets), I tried wrapping it with some method so that I can apply strategies globally, like not calling it more often than once every n minutes:
https://github.com/Interkarma/daggerfal ... throttling

I won't pretend it's a very clever strategy or that it works for all situations, but that could be a start...

I do not understand why you do this in CloseWindow() - gc intentionally takes place on window close - it does not hurt performance on UI window close
keep in mind we are talking about a mod calling gc - so why change the core if the mod does it

Nystul wrote: ↑Mon Feb 04, 2019 10:06 am I do not understand why you do this in CloseWindow() - gc intentionally takes place on window close - it does not hurt performance on UI window close

Right, maybe GC could be run unconditionally in this case; Yet this call needs to be wrapped too, so that the global strategy can skip more conditional GCs after that.

Nystul wrote: ↑Mon Feb 04, 2019 10:06 am keep in mind we are talking about a mod calling gc - so why change the core if the mod does it

Yes, if a wrapper is in place, then all calls should go thru the wrapper, even the ones coming from mods.
I don't know of a way to intercept all calls to the original UnloadUnusedAssets(), so with this solution mods would have to be modified too. Maybe they're better ways.

Nystul wrote: ↑Mon Feb 04, 2019 10:06 am I do not understand why you do this in CloseWindow() - gc intentionally takes place on window close - it does not hurt performance on UI window close

(that said I started investigating those issues because on my rig some months ago music was skipping each time the UI closed. It seems fixed now, but that's why I didn't make a special case at the time)

ah ok
hmm not sure why gc takes so long in the first place - could it be that it isn't called often enough and it's internal lists grow too much?

what makes it hard for me to reproduce your issues is that on my system the call of UnloadUnusedAssets() does not cause any issues or slowdowns.

Nystul wrote: ↑Mon Feb 04, 2019 12:58 pm hmm not sure why gc takes so long in the first place - could it be that it isn't called often enough and it's internal lists grow too much?

Well, that can be tested by calling UnloadUnusetAssets() every frame!

Outside near a castle,
no mods:
2000~2200 assets, 44ms (stddev 4ms)
full mods:
~5900 assets, 110ms (stddev 8ms)

Inside castle
no mods:
21000 assets, 57ms (stddev 4ms)
full mods:
~23000 assets, 122ms (stddev 8ms)

So it seems to have a pretty high base cost,
In all the tests I did MarkObjects dominates this time, so it is likely a function of the number of assets in memory when it is triggered (and according to those measurements must also depend on the kind of assets) rather than the number of unused assets.
PS From what I'm reading it is asynchronous though, so it shouldn't block the game during its whole execution. mmh.