Anyone know any improvements for this data saving script?

I’m just trying to point out the mistakes you’re making in your benchmarks, yet you decide to call me aggressive for no reason at all. Such comments aren’t allowed on the forums and is considered disrespective, as you’re being half subjective.

– You aren’t performing enough requests (3 is not enough).

That doesn’t matter at all, since you are saving for different keys.

– Saving to same key results in DataStore throttling.

This is why I suggested that taking average isn’t a good option, since for me, it never throttled and another request 2 times took exactly 0.3 seconds.

Pcalling is an fairly expensive operation, and shouldn’t be used on benchmarks as it just adds unnecessary time.

Again, all the tests I’m doing and explain indicate otherwise. Data saves successfully, you are claiming otherwise and keep repeating that without further elaborating. Such saving is rather expected behaviour than a bug. You can’t save data to the same key under 6 seconds (usually), but there are no such limits to saving data under different keys.

You comment is accusing me of spreading false information, which are not false, at least not according to this famous post on Stack Overflow: Concatenation of strings in Lua - Stack Overflow.

I just saw your topic, and yes, the information you told was false, the stack overflow post was made 11 years ago and a newer article about optimization in Lua has came out, which explains those.

If you read the topic, which you clearly didn’t:
local string1 = “A”
string1 = string1 … “B” … “C” —> creates one string
local t = {“A”, “B”, “C”}
string1 = “”
for i, v in pairs(t) do
string1 = string1 … v —> results in a lot of strings
end

This one is correct:

local string1 = "A"

string1 = string1 .. "B" .. "C" ---> creates 2 strings

local t = {"A", "B", "C"} -- A,B,C are already created above, 
-- therefore they won't be created again

string1 = "" -- 1 string "" created

for i, v in pairs(t) do
	string1 ..= v ---> lua will not create any more strings
end

My post is not off topic, it is to the point as it clarifies that string concatenation is not so expensive as you say it.

Pointing out how? By not argumenting them? By not pasting any sources? By not doing proper and explained tests?

Yes, I am responding to your bold accusations, unargumented points and repeating. You are designating my posts as invalid, while not showing reasons for any of readers to believe otherwise. You are saying I’m a liar, and that my DataStore knowledge is insufficient. You are getting seriously personal, so if I were you, I’d start questioning your own statements first.

As far as request times go, I’ve literally done all the tests you’ve posted, and got expected results! Not only that! Take a look at the following function, before you comment further, take a look at what it does, and observe the results (be it studio or server, even though server tests are more valid).

local DataStore = game:GetService("DataStoreService"):GetDataStore("123")

local start, finish, data

DataStore:RemoveAsync(1); wait(6) --> Wait for next allowed request.

start = os.clock()
DataStore:SetAsync(1, 2)
data = DataStore:GetAsync(1)
finish = os.clock() - start

print(data) --> Prints "2" immediately!
print(finish) --> Prints around 0.45 seconds (both SetAsync and GetAsync).

This is not a place to discuss string concatenation.
Why would you paste this information here anyway. At the same time, if your information is true, why does memory then so drastically increase the most when we use your loop that concatenates strings?

Doesn’t clarify, only claims. If you read through the whole topic, you would see the results of a couple of tests and see that both table concatenation and one-line concatenation (chain) are much more performant than your last option, that is supposed to only add to the string.

One small thing the others left out of their review is criticism on you allocating your functions to the heap.

Instead of defining your functions as so :

function FunctionName() end

You can allocate your function to the stack :

local function FunctionName() end

The stack and the heap in Lua are allocated to the heap in C, but, the stack is stored as an array, and the heap, as a dictionary. This gives stack memory slightly faster memory indexing than heap memory. Although functions allocated to the stack give a “negligible” boost, as some like to call it, it is a good practice to always allocate variables to the stack when appropriate. The main few reasons of why we use locals are for consistency and scope management.

If you want to see the results of the benchmark:

A fellow Developer Forum member by the name of “4thAxis” did some benchmarks on this matter. The results when ran come out to be ~0.00025 for locals, ~0.00068 for globals. Link

1 Like

I recommend switching your datastore to datastore2, as this is much more reliable, with 100% data loss prevention, and honestly a lot easier to use once you understand how it works.