When are data tables loaded into RAM?

Development Programming & Scripting Blueprint
, , , ,
1

Are data tables loaded from disk when a handle is made and unloaded when it’s broken? Or is there some other arrangement in place? We’re deciding whether to access directly from data tables or load into an array on startup and access from that, and we’re worried that fetching from disk often, and potentially in the middle of cutscenes will kill our performance.

2

I’d also like to kwow, for the same reasons :frowning:

3

Same here. It would be great to hear some comments from Epic staff. For example, info about Fortnite development and the way of DataTable’s usage in it.

4

I still don’t know, neither… Yes it would be nice some answer from Epic. We want to make a very intensive and real time fast use of previously saved data, and it’s crucial to know when they are readed from RAM and when from disk, so we can decide if we need a preload to array or not, just the same as BurnGameVen13 said.

5

I would also like to know about this. Does anyone know if there’s a considerable advantage to storing & retrieving the data through class variables, when compared to directly accessing them from the table?

6

Bumping this. I don’t know C++ well enough to dig into the engine and figure it out, but the answer is important!

7

DataTables are assets so as any other asset it is is loaded wither if you load something that reference it or manually with TSoftObjectPtr (TSoftObjectPtr | Unreal Engine Documentation), once that happens everything stays in memory until nothing is using it (not referenced anywhere anymore) then it’s unloaded.

If you circling thru large amount of data even in memory can freeze as you delaying game thread processes by doing so, so you should do that only when user don’t notice that.

1 Like
8

Finally!
Thanks!

9

I know the last sign of life here was over 7 years ago, but maybe someone will look after it still.
Two things you (all) need to know about the above.

  1. If you will make TObjectPtr and mark it as UPROPERTY and place it in your object, then yes, it is like @Shadowriver wrote, it will be loaded with that object and stays in memory, but…
  2. If it will be TSoftObjectPtr, then some things will be kinda different, and they are:
  • We all know, that we have to call .LoadSynchronous() on TSoftObjectPtr to load assigned asset, but did you ever wonder, what happened later? Did this object stays loaded like with TObjectPtr case? The answer is, YES. Becuase it’s TPersistentObjectPtr under the hood.
  • But the second and maybe the most important thing is, every call to TSoftObjectPtr, I mean, no matter if it is .LoadSynchronous() or .Get(), will make a series of checking, is the object is still valid and then will make dynamic_cast from UObject to UDataTable (which is expensive). So it is better to load it once and store as TObjectPtr later, rather than load it once and getting by calling .Get() on TSoftObjectPtr every time you want to access UDataTable

Hope, this will be helpful for someone.