Data management idea

[popochv]

Hi, I am working on a program that will run on 10 different PCs.

Each PC has 10 different contents (images, texts, videos) to show to a client.

and this program should be manageable by the client who doesn’t have any knowledge of Unity.

So, my plan was to build a program that can read data from the StreamingAssets folder based on the JSON (e.g., different image paths, different texts, etc)

and make another program that the client can use to produce JSON with contents (images, strings, videos) that are placed in specific directories, like an editor (let’s call this an editor program).

So, when the client wants to run a program on another PC with new content, all they have to do is to write JSON from the editor program and put that JSON and other content files into the StreamingAssets.

I have searched how Addressable, ScriptableObject, StreamingAssets, Resources.load work, and my conclusion was, as I said, the combination of JSON and StreamingAssets to load different contents on different PC.

At this stage, I wonder whether using the ScriptableObject has any benefit in terms of performance or memory management.
If I use a ScriptableObject to load data from the JSON, then the flow of content looks like this: Client ← Program ← ScriptableObject ← JSON ← StreamingAssets

Surely, addressable is easy to handle memory management, but it seems like it doesn’t fit to my scenario (e.g., dynamic changes of contents per PC)

and Resources.Load method is also limited which is not suitable for our client usage (needs to be built within Unity).

I used StreamingAssets and JSON combination on an Android tablet PC a few years ago, and at that time, the loading process was a bit laggy and had a bit of a hard time managing the memory issue.

So I want to know whether ScriptableObject has any beneficial effect in my scenario or should I go for addressable which I still do not fully understand yet.

It would be really glad to hear any expert’s experience/advice to handle this issue.

[Kurt-Dekker]

I’m not sure how anyone could even begin to answer this vaporware question.

Instead, start making your project, all the while paying attention to what is happening and how it is working out.

DO NOT OPTIMIZE “JUST BECAUSE…” If you don’t have a problem, DO NOT OPTIMIZE!

If you DO have a problem, there is only ONE way to find out. Always start by using the profiler:

Window → Analysis → Profiler

Failure to use the profiler first means you’re just guessing, making a mess of your code for no good reason.

Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.

Is it still worth optimizing square roots in 2021+?

It depends on the target architecture and runtime library of course, as all computer code runs on the actual CPU where your game is running, not some “theoretical magical global CPU of today” construct. But in 2021 a floating point unit (FPU) is pretty standard on most targets. All that said, don’t do needless work, especially on mobile, as that just burns down battery life. If you suspect you have a performance bottleneck, DO NOT START MAKING OPTIMIZATION CHANGES!! Instead, start with the …

Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.

Notes on optimizing UnityEngine.UI setups:

How to efficiently copy transform data into an array

Just so you know, the entire UnityEngine.UI system is available in source control from the package manager (and from github) and you can look at it and probably see there isn’t going to be a lot of fat. If there are some particular specific widgets you use in there that are too slow because of the use-generalization assumptions made, you might be able to get some benefit by tweaking them, but since so much of mobile performance bumps against pixel fill bounds, it’s unlikely to get you much ben…

At a minimum you want to clearly understand what performance issues you are having:

• running too slowly?
• loading too slowly?
• using too much runtime memory?
• final bundle too large?
• too much network traffic?
• something else?

If you are unable to engage the profiler, then your next solution is gross guessing changes, such as “reimport all textures as 32x32 tiny textures” or “replace some complex 3D objects with cubes/capsules” to try and figure out what is bogging you down.

Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.

This sort of speculative optimization assumes you’re properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.

[popochv]

@Kurt-Dekker

I’m not sure how anyone could even begin to answer this vaporware question.

Instead, start making your project, all the while paying attention to what is happening and how it is working out.

DO NOT OPTIMIZE “JUST BECAUSE…” If you don’t have a problem, DO NOT OPTIMIZE!

If you DO have a problem, there is only ONE way to find out. Always start by using the profiler:

Window → Analysis → Profiler

Failure to use the profiler first means you’re just guessing, making a mess of your code for no good reason.

Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.

https://discussions.unity.com/t/841163/2

Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.

Notes on optimizing UnityEngine.UI setups:

https://discussions.unity.com/t/846847/2

At a minimum you want to clearly understand what performance issues you are having:

• running too slowly?
• loading too slowly?
• using too much runtime memory?
• final bundle too large?
• too much network traffic?
• something else?

If you are unable to engage the profiler, then your next solution is gross guessing changes, such as “reimport all textures as 32x32 tiny textures” or “replace some complex 3D objects with cubes/capsules” to try and figure out what is bogging you down.

Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.

This sort of speculative optimization assumes you’re properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.

Okay, thank you for the comments, but that is not the one I was looking for.
I know such processes you described and how to optimize a program with the use of profiler.

I already have the program that uses json and streamingassets folder to load different contents in a program, and I wanted to hear any other developers who had experience in building a similar program like my scenario with the use of scriptableobject, json and streamingassets folder.

Because all I could find from other’s threads are not fit with my scenario.

I think it’s better to try myself first to see whether its valuable to combine it or not.