As a Roblox developer, it is currently too hard to measure the performance of module scripts in my games and locate performance issues from them.
If Roblox is able to address this issue, it would improve my development experience because it would allow me to much more easily identify performance issues without needing to struggle with the server sided microprofiler.
Originally I assumed this was a bug however a staff member confirmed here that it is not:
Other users in that post shared similar interests in seeing module activity inside of the Script Activity/Script Performance section. Currently module activity doesn’t show up at all and goes completely uncounted. It does not show up under the parent script’s total at all.
Being able to quickly identify scripts which are using lots of CPU would greatly improve my ability to narrow down the locations of certain performance related issues and better identify which scripts I can improve upon.
For example, my game uses a single starter script. This starter script starts several worker modules which end up requesting various service modules. These service modules end up registering most connections in the game and if activity was tracked for modules all of these connections that I start in the body of different modules would count towards activity somehow but all of the activity in my game shows up as zero besides the default Roblox scripts.
Here is a common example of how events are commonly registered in this way:
local entities = workspace:WaitForChild("Entitites")
local function addEntity(child)
-- Do some stuff
end
for _, child in ipairs(entities:GetChildren()) do
addEntity(child)
end
entities.ChildAdded:Connect(addEntity) -- This event connection goes completely untracked since the calling environment is a module and modules are not tracked in Script Activity/Script Performance
local SomethingService = {}
-- Service stuff
return SomethingService
If I were to accidentally use DescendantAdded but only my top level instances still pass the check the script activity would be much higher assuming I’m adding or removing a lot of instances in the Entities folder at once and it would be easy to identify the concern during regular testing and it would be easy to identify that it must be the event connection there since its the only thing connected in the body of the module.
There are a lot of cases where I have connected a more expensive event without knowing it and later ended up having to go through lots and lots of debugging to locate the issue. To make things worse, the microprofiler doesn’t help here because this usually isn’t something I would profile, and, if I did it would not clearly reveal the problem unless you pay attention to all of the blocks in the microprofiler and make the connection that there are too many there.
The server microprofiler can be a bit annoying to work with since you need to download the results, go into your logs folder, and view the HTML file in a browser. That’s not something I want to do in Studio especially, and, while in Studio I believe I can use the microprofiler if I switch to the server view, it’s still not as concise as seeing the script activity fluctuate so much is usually a really good tell that something is up if its a simple event.