Whenever I press “Publish to Roblox” studio freezes and takes 10s or more before showing the dialog.
Pressing “Create New” freezes studio once again, because why not.
Of course, actually uploading something also takes a year and a half.
Does anyone else have this?
Is there a way to fix this?
(My internet is bad, but not so bad that it takes 3s+ to download the dialog, less than a MB) (Why does studio still not do http async? Does studio really have to freeze every HTTP thing?) (well although HttpService asset loading is async, unless you insert stuff from the toolbox)
Also seems to be linked to RAM usage: (Green=CPU, Yellow=System Commit, Red=Physical Memory) Normal RAM
After pressing "Create New"
(It raises from 700MB/700MB to 1100MB/1000MB and drops when the GUI finally loads) (yes this is actually how long it takes, the GIF might be recorded at 10FPS, but is real-time)
I’ve never personally had any issues with this. It certainly hangs for a couple seconds though. Uploading models and places never takes more than 1-5 seconds though from what I can remember.
It would be nice though if this whole flow was changed. I agree that it should be asynchronous (as should any HTTP call be whenever possible). That would make it feel a lot smoother at the very least. I’m not sure why these tasks are taking your computer so long though.
The RAM usage while uploading a simple animation is incredible:
Red arrow: 291MB
Blue arrow: 1.4GB
Total time: 3m (although I have to admit that this time it took EXTREMELY long compared to other uploads)
Just using “Publish to Roblox” (no dialog needed) is almost instant.
The only delay there is a very small one, which is normal for uploading something with crap internet. (although honestly it uploads much much faster than I expected, although it’s a small place)
EDIT: Uploading a video.
I started recording, clicked “Publish to Roblox” and stopped recording once the GUI loaded.
It took 3 minutes, most time spend using RAM, while network usage was practically nihil. EDIT: Uploaded:
on the topic of bad internet connections and how it affects performance in studio.
has anyone else noticed how just trying to test something solo, it freezes studio until either A: the connection finishes, or B: your disable your network connection.
It certainly isn’t the most graceful when it comes to being offline! I guess the movement to even more cloud-based assets makes it all make a bit more sense though. The amount of HTTP errors/warnings should be blocked out though. (On another note, how about better logging and the ability to sort the console log based on the level of severity?)
What really irks me is that Studio requires an internet connection to even open. It works perfectly fine if I open a place and then disconnect my computer, but if I want to open a new or existing file then I need an internet connection.
I’m also pretty sure that Studio / the website is doing something horribly wrong here.
I often have studio totally hang for up to 30 seconds when publishing to Roblox, and occasionally have it hang for up to 15 seconds when “Play” functionality to test.
There’s no reason for Studio to do that, even if it is legitimately waiting on the network (which I don’t think it is, given that about half of publishes happen pretty much instantly) it should at least be done asynchronously with a responsive modal dialog so that you can cancel it.
After some playing around with Process Explorer, I made a small discovery:
If I suspend the only mswsock.dll thread, studio doesn’t freeze or eat RAM. (it just waits forever)
When I resume it, that’s the moment studio freezes and starts eating RAM.
Apparently it’s the HTTP requests itself that somehow do this stuff…
Also goddamnit the waiting and freezing is annoying.
EDIT: Actually the HTTP stuff is fine.
It’s the QtWebKit4.dll that uses the HTTP stuff that eats the RAM. (Which also freezes the GUI, which makes sense as it is the GUI’s DLL, no?)
GIF of the QtWebKit4.dll thread: (although that dll name doesn’t appear in the Stack anymore)
(If I spawn-refresh the Stack window during The Big Yield, it’s 99% of the time QtWebKit4.dll stuff) (for some reason while I took that GIF it didn’t appear a single time, which is weird on its own but eh)