When selecting a large number of objects, or grouping a large selection of parts, Studio seems to now lag a significant amount.
To reproduce, turn off all plugins and try selecting, and then grouping, any of these clusters of parts in the attached file: SelectionLagRepro.rbxl (25.0 KB)
Frame 43 in the attached microprofiler dump might be insightful It seems possible that some built-in plugin that watches for physics collision groups in selected parts is running in the background, listening for selection changes, and performing expensive work: microprofile-20191229-180420.html (4.7 MB)
I am not able to reproduce this. Even if I select every part in the place via drag select in the viewport and group them together, I am able to then drag around the parts without issue.
Am I doing anything differently than you are?
As for the builtin plugin checking collision groups, that would likely be the Collision Group Editor. You can try temporarily moving it out of %localappdata%\Roblox\yourStudioInstall\BuiltInPlugins temporarily and seeing if that stops the LegacyLock.
That appears to be the same thing I’m doing, except there is about a second or two where Studio locks up after hitting Ctrl-G, and while rectangle selecting, it locks up for about half a second while moving the mouse.
So here is 161 parts right, group that, its like, 1 second, or so, that it takes. Now, as an architect, this is super duper frusturating to deal with on a constant basis as I am grouping things of various amounts to make up my floors, support columns, a bunch of windows, and much more (all consisting of hundreds to thousands of parts).
Sorry, I misread the OP and thought the performance problem was dragging. I am able to reproduce the performance problems with selecting and grouping, even with all builtin plugins disabled.
If this hasn’t always happened, when did it start? Also @CorrivalRhyme
Is there a fix in the works or in the pipeline to be released soon?
I have run into an issue where it stops responding and eventually disconnects me from the TeamCreate server after about two minutes when trying to group and ungroup large amounts of parts.
No. We stopped receiving replies to our questions above & the delay was reported as only 0.5-2 seconds, so it appeared this bug was not important to developers.
If this bug is important to you still, can you follow up with the following?
Has this always happened since at least a year ago, or did it start recently (e.g. x months ago)?
Is the 0.5-2 second range reported so far not accurate? Studio would need to be locked longer than that to disconnect from Team Create. What times are you experiencing, and with how many items selected? Can you provide a repro if you are experiencing this more severely?
Does temporarily removing the CollisionGroupEditor.rbxm from BuiltInStandalonePlugins & BuiltInPlugins are reported previously completely resolve the performance problem like reported above?
After thinking, I do remember instances from over a year ago with Studio not responding when selecting a significant amount of instances. However, today is the first day when I needed to ungroup a significant amount of parts and this issue made it extremely difficult to do.
The amount of time Studio takes gets progressively longer depending on how many objects are selected. For example, Studio stops responding for about a full minute with about 850 objects selected.
Removing all plugins from BuiltInStandalonePlugins and BuiltInPlugins did not make any difference.
After further investigation, it appears performing any action on a large amount of instances takes a long time to finish.
Some actions, such as grouping, take longer than others. However, even an action as simple as renaming 850 parts, from the repro, did take around 11 seconds to finish.
I went ahead disabled all installed plugins and along with removing all plugins under BuiltInStandalonePlugins & BuiltInPlugins again. However, the issue still persists even with renaming.
The renaming issue is likely separate from the rest and caused by our performance bottleneck in the Explorer being… calculating the size of the horizontal scrollbar. Updating the Name may lead to the canvas size changing, so we end up performing the expensive operation of recalculating scrollbar size. Conversely, this means that if you change properties that don’t affect scrollbar size or close the Explorer before renaming, there is no need to recalculate scrollbar size, and the operation is instantaneous.
We investigated refactoring the Explorer to improve this, but it was a substantial amount of work. Given the OP only has 4 likes & hasn’t received much community attention, we can’t promise we’ll be able to do this anytime soon, but that can change if this becomes a major community ask.
As for the other performance problems, it looks like they are related to the plugins you have installed (possibly our own). If they still happen once you disable all user plugins while running BuiltInPlugins, we can investigate further, but otherwise you’d need to report it to the appropriate plugin author.
Thanks for the info! Closing the explorer makes the renaming operating almost instantaneous.
After reinstalling Studio and disabling all installed plugins, there is still that slight delay as originally reported. However, it appears that one of my installed plugins is the major offender here so I will try to track down which plugin, investigate, and report to the plugin author so it can hopefully be fixed for other developers using the same plugin.
Maybe you have a fast device, this lag is getting reproduced for me, maybe is because i selected them very fast, normally that happens to me, or maybe because my device is not very fast.
After a little more investigation, I did find the plugin causing the issue. After digging through the plugin’s source code, I found an odd behavior with the SelectionChanged event that also explains why the collision groups editor plugin is causing the performance issues.
It appears that when grouping and ungrouping, every selected instance will be unselected one at a time, or vice versa, causing the SelectionChanged event to fire every time. This behavior seems unexpected as it should only fire once with all the ungrouped parts selected or the newly grouped model selected.
Collision groups editor demonstration
I edited the builtin collision groups editor to print to the output every time it calls SetStateAndRefresh because of a selection change.
It seems possible that some built-in plugin that watches for physics collision groups in selected parts is running in the background, listening for selection changes, and performing expensive work: