I have a specific scenario in which a bulk amount of parts have to be pushed to clients. If the only properties of the part that will ever change are the size and position, is it even slightly more efficient to create the parts in the workspace and allow roblox to replicate, or should I make a remoteEvent to do it?
Both will always take the same time as they both are dependent on latency.
I was more interested in packet size, as in whether Roblox is optimized enough to tell the client this:
{
Object is of class Part
all properties are default
except Positon which is vector3 yada yada
also parent is workspace
}
instead of passing all the properties regardless of whether they are default or not.
You won’t be able to know that without reverse engineering or packet sniffing, but either way it won’t matter. You’re getting into micro-optimizations at that point.
Network usage is no joke, it’s worth optimizing. Why not test it out experimentally?
Agreed, Try making a testing server and work out any kinks with the remoteEvent.
Will do. Will edit when finished. This should be fun.
EDIT 1: Place is published here; Will be running tests. Place is uncopylocked if any of you want to investigate further.
EDIT 2: Raw data:
Trial | Replication Type | Console Printouts |
---|---|---|
[1] | Fresh Server - Standard Roblox Replication | Client Console: ![]() Server Console: ![]() |
[2] | Fresh Server - Custom Replication (Objects only on Client) | Client Console: ![]() Server Console: ![]() |
[3] | Server from experiment 1 - Roblox Replication | Client Console: ![]() Server Console: ![]() |
[4] | Server from experiment 2 - Custom Replication | Client Console: ![]() Server Console: ![]() |
[5] | Server from experiment 1 - Custom Replication | Client Console: ![]() Server Console: ![]() |
[6] | Server from experiment 2 - Roblox Replication | Client Console: ![]() Server Console: ![]() |
timestamps are in tick() & os.time()
gonna go to sleep 1:47 AM me is dying
Oh, and I don’t know if you know this, but you could monitor network usage by pressing ctrl+shift+f3,
Run both tests on a live server. Count how much total data was received by the client before and after each test was run. That should be enough to get your answers.
You might want to tone down the number of parts created, btw. 10000 is a bit too much. Try something like 1000 or even 100.
I don’t think this is confidential at all, considering you can probably easily reverse engineer it anyway.
As far as I know, the replication layer does take into account default properties, so you’re fine.