A very specific use-case, which I will not go into, has required me to use a lot of folder instances, or rather, instance-based organisation methods?
Anyhow, I am wondering if this can stack and quickly turn into an issue for memory. These folders will have 3-5 attributes to go along with them.
Does anyone have a statistic on something like 100-1500 folder instances, in terms of memory usage? Does anyone have a better idea for organisation?. I have obviously thought of tables, but I am not sure on how to make this system work with tables, efficiently, so I will not be using tables.
However, folders are already extremely cheap memory-wise. They only have four properties and those properties barely cost anything. 3-5 attributes, as long as you’re being smart with it, won’t kill the performance of your experience.
Even a game with ~2000 models has no issue, and those have a minimum of 10 properties.
It usually matters what is inside the folders or models that causes memory issues. But simply having attributes on folders won’t do anything unless you have hundreds of thousands.
Do you have any idea on the performance impact of require(), if called 100-1500 times every frame, or every second or third? I.e is require() an expensive function? I could use tables, i’m just not sure how it holds up to folders. Better or worse?
Usually it’s best to call require() once at the top of your script that uses it. Calling it once makes it run, anymore calls after that it’s cached so it’s not really a performance drainer.
Using tables or folders really depends on the structure of your experience and what you’re using the folders for. You could also look into CollectionService (tags).
The issue I have with tables is replication of ModuleScripts, and the caching. I would constantly need to re-require in order to get updated information, and they do not replicate from server to client. CollectionService is completely obsolete for my use-case.
I’m using the folders for replicative information organisation. Server → client or just the client itself. If the memory impact is negligent, then I guess I’m fine with the folders. Would be cool if they could add some sort of replicative element for storing data within modules.
Calling require many times is less efficient that locally storing the result in a variable, though it’s not that bad because Roblox cashes the result after the first time you store it (i.e. it doesn’t rerun your whole module each time you call require and just stores the returned value).
I think you should reconsider your secret use-case, since there isn’t a good reason not to format anything involving Folder instances as a table that you pass around.
Re-requiring doesn’t do anything, since Roblox cashes the result. You need to modify the table your module script returns–that will be updated across all the scripts that require it (at least on the same side of the server-client border).
If you want a table to replicate, consider ReplicaService, which is made by loleris.
I think you might want to rethink your method. There is logically never a reason a table can’t be used instead of a folder, besides replication, but replication can be done with ReplicaService for tables, so then there is really never a reason.
I meant re-requiring after modifying the table values, but the tables do not replicate. Again, server → client .
As for ReplicaService, you can share your experiences if you have any, but I am not sure it would work for such a large scale. Do you know of it’s performance?
local moduleTable = require(someModule)
moduleTable.Fizz = "Buzz"
print(module.Fizz)
and
local moduleTable = require(someModule)
moduleTable.Fizz = "Buzz"
-- In some other script
local moduleTable = require(someModule)
-- Need to wait a sec just in case this code executes before the other scripts, since they have equal execution priority
while not moduleTable.Fizz do task.wait() end
print(module.Fizz)
Will all do the same thing and work identically. What happens when you call require is Roblox runs the module script, gets the return value, and stores it in memory. Each time you call require after that, it sends a reference/pointer to the same bit of memory (ie all the scripts are working with the same table in memory). It’s like having a local variable but it goes across scripts.
ReplicaService is absurdly performant (easily faster and more memory efficient than using Instances, which are bogged down by lots of extra data and things). It only sends changes to the table across the network, and does all sorts of things to increase the performance. The table you replicate can be of any size but it still will work just as fast.
Per the description:
“It don’t go brrrrr” - ReplicaService is completely event-based and only tells the client the data that changes - it keeps the network usage low and conserves computer resources.
(Loleris is basically a genius–also the creator of quite a few huge games.)