How to reduce lag from in pairs() loop

im making a system where the client sends to the server a string and then the server starts searching in a table that has 554+ children each are string values, so basically what my script is doing is searching throughout these children if the value of the child is the same as the string sent and if so then destroy that string value

but the problem is that the micro profile of the game spikes and causes lag, also the string value has to be destroyed in the server and not in the client and i cant put a wait() because i want the value to get destroyed as fast as possible

heres the script

-- local script

Button:Destroy()

game.ReplicatedStorage.StringEvents.RemoveStringEvent:FireServer(Button.Name)

-- server script

game.ReplicatedStorage.StringEvents.RemoveStringEvent.OnServerEvent:Connect(function(client, ElectronicName)
	
	for i,v in pairs(client.StringsTable:GetChildren()) do
		
		if v.Value == ElectronicName then
			
			v:Destroy()
			
			break
		end
	end
end)

Only store strings inside the StringsTable(not instances) that way you will be able to use table.find that is optimized and much faster than what you’re currently doing for large values of N. I’d suggest storing all the strings inside a single StringValue in CSV format(comma seperated values). This assumes that all the strings combined don’t have a length bigger than 200k characters and that the character “,” doesn’t normally exist in any string(so it can be used as a separator). Here’s an example of how that would work:

--Fetch the stored strings
local t = client.StringsTable.Value:split(",")
--Find the string using a quicker search method
local index = table.find(t, ElectronicName)
--If it exists, remove it
if index then table.remove(t, index) end
--Update the string table and save the changes
client.StringsTable.Value = table.concat(t, ",")

If you want to also include "," in string names you can use game.HttpService:JSONEncode and game.HttpService:JSONDecode instead to safely serialize and deserialize the string array. If you need more space than 200k characters you can make a system that “cuts” large strings into multiple string values of 200k length and recombines them when needed.

3 Likes

well i cant trust that, because i forgot to mension that this is a inventory system and in order to create special electronic strings i use this formula:

“String”… math.random(1,9999999)

so not just that the strings will probably combine to be more than 200k characters also the player could have hundreds if not even thousands of items in his inventory that will eventually combine to be 200k+ characters because there isnt any limits of the items you can own in my game

but im thinking of flipping the thing so the name of the string-value becomes its value and the old name of the string-value becomes its value (if it sounds confusing then sorry idk lol)

and then use FindFirstChild(ElectronicName)

but any suggestions will be appreciated

well, i realised that lua probably uses a for i,v in pairs loop to findfirstchild so using that too dosent work

but i decided to do anyways and sadly yes, it still lags

so im open for suggestions

I’m 90% certain there’re many patterns in your data. You can consider using a compression and decompression module on top of the csv values, for example you can use Text compression by 1waffle1.

Only changes you need to make is convert it to a module and expose the compress and decompress functions. So then you can do:

local t = decompress(client.StringTable.Value):split(",")
--rest of the previous code
--saving:
client.StringsTable.Value = compress(table.concat(t, ","))
1 Like

thinking about it now, i think ill make a limit for the amount of items you own, i think that is the safest and easiest option, and thanks for your help.

As I said there’re patterns in there, it’s near impossible for any game to have large amounts of unpredictable data. Consider investigating your tool generation logic and the relationship between said tools, it might give you the answer.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.