How to measure how Expensive "Code" is


I have seen many threads revolving a similar idea


How expensive is it to create a new metatable?

IntValue.Changed:Connect is it “expensive”?

Is WorldToScreenPoint expensive?

Is math.random() expensive?

Expense of RemoteEvents and RemoteFunctions

So to measure how expensive something is can be done by figuring out how much Memory does something takes (that’s how I understand it)

So a Boolean probably takes 1 Bit for example

My question is "How can one measure the amount of memory consumed by one’s code?"

Readability is my number 1 priority, so don’t worry about unreadable code I hate those.
Never sacrifice readability for performance.

Would also be nice if we can also measure the amount of memory consumed by Instances

I have also found DataCost which can be used to measure how much Data does something cost for Data Persistence however they are both deprecated

I don’t know if it can be used for accurately measuring how Expensive an Instance is


Expensive code does not necessarily mean code which uses lots of memory, it also means code which runs really slow or otherwise bogs down the overall performance of your place.

You can use the script performance tool built into Studio to look at some of that performance info:



The names of your scripts are on the left. The Activity of a script tells you how expensive it is to run. Lower is better!

There’s more details on this page about diagnosing and fixing performance issues:

Hope this helps! :3


This is indeed helpful but there are times when we need to measure a small section of Code.
Script Performance measures how entire Scripts runs

It is a useful tool to pin down which script is causing problems in a game that has many Scripts, however If I have only 1 Script then finding which small section of Code is causing problems couldn’t be done with Script Performance


Do you currently have a performance problem or are you trying to do premature optimization? You shouldn’t worry about optimization until you actually have a problem.


You can’t do that if you have a game with Players.

Performance is important because not everyone has a High End Device, especially if your game is open for Touch Devices.

Some people could be using a Toaster to play your game and you don’t want them to have a bad time.

I am not saying that you should over optimize everything but it’s good practice and knowledge.

Prevention is better than cure . It is better to stop something bad from happening than it is to deal with it after it has happened.


Something I like to do is this:

local startTime = tick()

-- run code here

local endTime = tick()
print("Code took", endTime-startTime, "seconds to run")


Premature optimization is not good practice at all. It often leads to utterly unreadable code.

I’m not saying to flail your arms on the keyboard and write whatever gets the job done. Don’t write wasteful loops or do intentionally terrible things. Write the smartest code you can without sacrificing readability. Only if you start to see players having problems do you find and optimize what’s causing the problem.

You can use the script performance panel mentioned above to get a clue as to where problems might arise. You can use the microprofiler to see execution time of code chunks. You can analyze code for time and space complexity. But all of this is still subjective and should only be optimized if it’s a problem.


Don’t worry about that, Readability is my number 1 priority. I’ll mention that in the OP

MicroProfiler can come in handy


They are correct in saying that you shouldn’t optimise before you have performance issues. However, something they missed is you should test your game on different devices before release, especially low end and mobile devices.

If any performance issues come up when you test your game on different platforms, that is the time to start optimising. If you optimise before there’s any performance problems, all that ends up happening is your code becomes less readable and maintainable, and potentially more error prone.

edit: ninja’d


I would never write code in such a way that compromises my code even more, no one should do that.

I believe that it is important knowledge for specific topics for example using BindToRenderStep, in this case the better your code runs the better it is for the game in general.

Another Example would be FPS games where a Gun Script Performance is crucial and will effect User Experience and Game Play.


I don’t think you will find answers to the “is it expensive” questions being asked in those links in your list by adding up the memory footprint of variables in your game (if that’s even possible with a script… A Boolean in Lua is almost certainly a class, and way bigger than a bit, with other overhead, etc). That said, the Memory Analyzer is another good resource if you need to look into memory usage. Too many textures, in particular, can be a problem with mobile it would seem.

Answers to performance questions can be highly specific, and solutions can often require design trade-offs between a handful of options that have been exposed to the script writer through the API. There isn’t really a catch-all solution, which is why there are so many threads that seem to ask almost the same thing.

When you run into a performance issue, try the things that Elttob suggested (and search for solutions that others have already worked out for the same or similar problems), and then post your own question about your specific issue. That’s what I would do.

Developing performant solutions to interesting problems is not usually a task that a typical script writer should stress over at length. Identify the problem, play around with options until you run out of ideas, and then lean on your Comp Sci neighbors for advice.


That doesn’t mean you micro optimize your guns. If your guns work fine and responsively the first time you code them (without express thought of max performance), you DON’T micro optimize it.

Don’t optimize until you have a problem. Test on mobile devices to see if you have a problem.


You shouldn’t go by rough ideas of what you think would constitute a type. A Lua boolean is probably more around 4 bytes (not counting the TValue overhead Lua has). This kind of analysis of memory is probably not what you’re looking for; it won’t always be exact/the same.


I said probably & for example

On other platforms Booleans are 1bit sometimes more

But it’s good to know that it’s 4bits :+1:

My reasoning for meantion that is because other platforms at least Unity does tell us what type is how many bits, maybe Roblox has that too.


Unless there’s a built in specialization for the language you’re using for memory efficiency, this is not the case. Platforms tend to pad their types to their register size. It’s also dependent on context, so it’s not something to worry about unless you’re dealing with large collections.

4 bytes, so 32 bits. Double that on 64 bit programs.


Isn’t the larger size a direct result of the lack of static typing in (scripting) languages? I’d imagine you can’t (afford to) allocate less than the size of a pointer for any variable without it.


I can’t speak for every implementation, but Lua’s TValues are a tagged union, so naturally their size is padded to their largest non-gc type, which is usually doubles. It’s the overhead you pay for having a language where variables can change type, yes. Static typing in a scripting language also probably wouldn’t fix it because you’d still be using its underlying stack impl.