Thanks! Seems like it’s only enabled on the main place in my experience. Should I fill out the survey with the other places as well?
1 Like
Yes, please - that’s the most reliable.
1 Like
This is so cool! Is it possible to download server dumps in binary format? 
1 Like
Yes, if you follow this example 10-usecase-snapshot-sender.luau. It requires some setup. There isn’t currently a UI feature for requesting binary dumps from servers, but in the future, HTML dumps will transition to the new internal format. Once that happens, they’ll all be agentically profileable, parsable through LibMP, and viewable in the browser.
UPDATE: For all your registered games, LibMP is now enabled for every Place ID they include, even if it wasn’t explicitly listed when you filled out the survey.
is it possible to use this library to trigger a microprofiler html dump from a game script? my game has a complex startup process that i’d like to analyze with the microprofiler, and trying to time the ctrl+p to when it runs has gotten very old. even when i have been able to time the pause, it seems like the buffer containing profile data has already overflowed, and so there’s nothing to analyze unless i reduce the startup load to a small fraction of what the game is meant to support. is there a way to increase the size of this buffer?
1 Like
I see several requests here:
- Saving dumps to files programmatically.
- Saving dumps as HTML rather than a machine-readable binary.
- Capturing more frames at any given moment (better buffer management so they overflow less often).
- Continuous capture, making it easier to profile the startup sequence.
All of these are on the TODO list, but none of them is available yet.
#1 is planned, but only for Studio. For clients, we’re considering uploading captures to our servers and returning a URL instead.
#2 HTML output will definitely be supported. It’s also planned to upgrade the format so it becomes machine-readable, just like the binary dumps.
#3 is a high priority, mainly because you should be able to set a memory limit for the buffers so MP doesn’t exceed it in production games. As a consequence, MP should also be able to dynamically redistribute the allocated memory across OS threads based on their actual fill rate, making much more efficient use of the available space. This should allow us to fit more frames into the same total buffer size we allocate today.
#4 We have internal demand for this as well. I experimented with a feature where you press “Start Saving to Disk”, let it continuously save a full minute of gameplay, then press “Stop Saving” and end up with a large number of frames saved. There’s still quite a bit of work needed before this is ready.
Not sure how feasible it is but for #2 I would suggest new html dump system that could generate a .html from the machine readable binary that we are able to obtain, and then exposing that generator to us (maybe in a CLI?) If we could get an html from that binary then there would be no need to make the html machine readable, since you could just always export in .gprx and then generate the html later on your own time. Perhaps in studio you could then choose to export in .gprx, .html, or both. Personally, having the .html generator would eliminate the need for #1, since I could just send the generated buffer to a local node js server with the http service and then invoke the cli from there. Just a thought, though.
1 Like
Yep, I agree. Absolutely doable and useful.
1 Like
Here is an experimental converter. The README is included inside.
gprx2html_dotnet_alpha0.zip (521.3 KB)
Hey @ZenMa1n – a follow-up question; you caution in the post about increased memory usage when enabling LibMP; do you have any ballpark estimates, to know what we’re dealing with? I’d love to capture data from the lowest-end devices (old phones/tablets), however I’d be worried about them crashing before even getting the data 
1 Like
Yeah, I meant specifically enabling MP (making it collect frames in the background), not requiring LibMP in your scripts. LibMP was designed to make only rare and tiny memory allocations, and even under heavy use in the Demo Game above, its core code footprint is just 0.6 MB.
Without enabling MP capturing, you can still open a LibMP session to see which timers in the engine or scripts have ever been visited and read the counters (although this mode still needs some improvements).
On the other hand, activating MP via LibMP.Control:EnableCapture(true) makes it allocate all of its buffers upfront, which amounts to ~90 MB on mobile and 150 MB on desktop. That’s a lot. Part of the work toward a full non-beta rollout is making it possible to say from scripts, “I’d like to capture the last 50 frames, but not spend more than 6-7 MB on that”, so MP could be enabled for all game sessions, even on low-spec devices. Currently, activating it for some % of game sessions is best because you get valuable samples from production, and the overall out-of-memory statistics will still be fine.
1 Like
I built internal analytics tool for our game; I cannot state enough how incredibly useful this has been!! Roblox’s analytics have been great, but have always been lacking in granularity & filtering based on our specific needs. I’ve already boosted our players FPS by +10 in some maps thanks to being able to build this!!
My #1 request would be seeing the script labels, though I’m already aware its being worked on 
1 Like
Wow, thanks for sharing and for being brave enough to try this as one of the first. Great results!
1 Like
What does negative ms mean on a MicroProfiler log?
Could you specify where you’re seeing it? In the HTML viewer logs, or in the negative GPU frame times?
1 Like
Yep, GPU timings are a bit bogus and tend to go negative every several dozen or several hundred frames, depending on the platform and GPU vendor.
1 Like
what about full red bars that say “Ring Buffer” on within the microprofiler at certain times when only running on one thread or a bit bit more?
The thing is that each thread has its own ring buffer where scope enter/leave timestamps are written. Over time, the buffer naturally wraps around, and newer timestamps start overwriting the older ones at the beginning of the buffer.
When saving a dump, the engine strips the beginning of the buffer. However, because the buffer is being written to continuously, some writes may occur after that check, causing wrapped-around entries to leak into the dump. There are also a couple of bugs that can lead to this. As a result, the viewer detects these entries and marks them as suspect. Typically, there are only a tiny number of them, but for reliability, the entire first frame is marked as suspect.
In the next release, I’ve fixed a couple of bugs, so you should see the red “ring buffer wraparound” warning much less often. It will also be easier to identify which thread is actually limiting the number of frames you can capture.
1 Like
I also filled out the survey a bit late, when could I expect access to be granted? Would love to start using this in my testing place and potentially even live game as soon as possible.
1 Like