Would be super appreciated if the deleteDeferred
label would provide the objects that were destroyed; our team had to spend four days identifying the performance leak because the microprofiler would only show a 60ms-long “deleteDeferred” label, with no further information.
It’s not graphed terribly. Flamegraphs are very common in performance, and microprofilers styled like that are also very common.
Just because you don’t understand it doesn’t mean it’s bad…
Came to read about new update, left with a great banger
This new MicroProfiler looks awesome!! But I’ve opened up my game’s place in Studio, and I only see what looks like an older version. All the tabs at the top look very different from the tabs shown on all the new previews. I can’t find the X-Ray tab to try out the new features. I’ve attached an image below of what I see.
Also, the MicroProfiler (at least the version I have) has some tabs obscured on the right side when using device resolution emulator. Here’s an image of what it looks like.
This is amazing, I was just talking with my team last week about how nice it would be to have better visibility for memory profiling. Will try this out for sure.
Is this related to server dumps or client dumps? If it’s about server dumps, I’m commenting in this thread.
In short: the workaround is to create a server dump, and immediately after the first (non-functional) dump is completed, start recording the second dump right away, and it will be valid.
Regarding when the issue appeared - X-Ray mode was added in July (except for Windows), but I think the bug actually started later?
This new MicroProfiler looks awesome!! But I’ve opened up my game’s place in Studio, and I only see what looks like an older version.
All the features described in this update are only implemented when opening captures in the browser. This is mentioned in the full article, but unfortunately, it was removed from the announcement post to make it shorter.
In short:
Press the tiny Dump → NN frames
button in the MicroProfiler on-screen UI to save the capture as an HTML file in the same folder as the logs (on Windows, it’s C:\Users\<Username>\AppData\Local\Roblox\logs
).
- Do these allocations include C-based allocations (Like creating a new part would be an allocation)?
All memory allocations are displayed, including internal C++ Engine allocations, regardless of whether they occurred independently or were triggered by Lua scripts.
- Will we get a way to isolate a specific tag?
Are you suggesting isolating it during the dump creation phase or during the display phase in the on-screen UI or browser UI? If it’s the latter, at least you can currently use Ctrl+F to find the desired tag.
- Are there any plans for a Luau-sided API around the microprofiler and the data it collects, for things like analytics?
We are discussing this internally. The foundation of the MicroProfiler was developed with the assumption that it would be continuously enabled only for developers, not for all users, due to the slight overhead it introduces. Adding such an API without changing the foundation would allow us to quickly implement this feature, but we might not be satisfied with the result. Therefore, as a preliminary step, we first need to create an always-on, almost-zero-overhead mode for the MicroProfiler. This is an invisible part of the work but very significant.
- Will we be able to see all side effects of a specific event in the microprofiler?
That’s a good idea. We have considered tracking other side effects, such as how much memory a model will ultimately consume upon loading. These tasks can be labor-intensive, but I believe some of them could be implemented. We need to explore this topic further.
I’m glad you like it!
We planned to release the diffs closer to the end of the year, but since we managed to finish this feature earlier, why not release it right away, right?
As for zooming in, it seems that zooming and the find feature are the most welcome additions overall, haha.
That makes sense! I was starting to realize that it might only apply for captures and not the regular view.
That said, I’d love to see X-Ray view for the regular, moving view of the MicroProfiler. This will make it easier for younger/less experienced developers, as recording captures can be quite a skill curve.
I’d love to see X-Ray view for the regular, moving view
Yep, I agree. We have it in our plan.
Wonderful! I’m very glad to hear that, thank you!
This function can help me in the future
These are absolutely insane updates, great job at Roblox.
Including argument data is memory-intensive. This means we’d be able to display far fewer frames. However, your suggestion has got me thinking - maybe we can add detailed info only to those scopes that take an unusually long time. It’s worth researching.
Adding onto this; I saw no documentation on certain scopes, even after extensive searches on different engines. It’s not immediately obvious what a scope does sometimes, and I need to know when to blame you, not myself
For example, WaitForLock - who knows what it does other than the most highly esteemed engineers; but it chews up 30ms intermittently and that translates to stutters and I don’t like it and I’d love for it to be documented so I can plan ahead for a countermeasure.
Please please, pretty please?
Would be super appreciated! Since we’re spitballing ideas: it would be super awesome if the client could attach some small basic data, to describe what the user was doing at the time. Our game for instance has a lot of different gamemodes and worlds, and so being able to prepend this information into the microprofiler dumps we receive from users would be amazing!
This is my current foremost issue with the microprofiler - scopes are not really documented anywhere. You may get lucky if it has a useful name, but otherwise it’s difficult to pin down. Hope comprehensive documentation can get released at some point.
This is very nice, thanks for the link! Don’t know how I missed it. I imagine some stuff is still missing, but this is quite a bit of tags.