It has been mentioned on this topic that there are some performance issues associated with using gizmo, but only for FPS.
Recently, I did a test for my project and found that moving gizmo consumes memory, and when the movement stops, the consumed memory is not released.
Test PG:
Test result Graph:
It is expected that when you stop dragging for a while, memory should fall back to its starting level
I tried to use the Memory profile of Chrome with your PG. I took one heap snapshot before dragging the gizmo, and one after. Then, comparing the snapshots:
As you can see, the biggest “Size Delta” is for “(compiled code)”, so it’s Chrome internals. It’s only 250Kb, so it’s quite far from the >15Mb delta we can see in your screenshot.
It’s hard for me to make something of the other lines in the report, but if you do the sum of “Size delta” for all the other events, it amounts for ~150Kb.
Here’s another test result
We can see that some time after stopping the drag, the memory value does not fall back to the original 30.1 as expected 
I don’t have that problem here. The edge browser.
Refresh browser
→ Wait 10 seconds
→ Turn on performance monitoring
→ Wait 10 seconds
→ Drag and drop for 10 seconds
→ Wait 10 seconds
I tried again
those are my steps:
1.reload page，F12 and switch to Performance panel
2.wait for more than 2 min (make sure the memory is stable)
3.start Record
4.wait for 1min
5.drag gizmo time and time again，keep 5 seconds
6.stop movement
7.wait for 1min
8.click stop button
I tried a couple more times…
Sometimes it’s the same as yours, sometimes not.
The difference is whether I mouse over the arrows before waiting.
It is possible that some of the extra memory used is due to the material used during hover and drag.
It’s possible we are creating some objects (like the material when hovering the arrow) the first time you drag and that we keep them for future reuse.
cc @Cedric in case he would know more.
I’m self-assigning this thread. I’ll take a look this week to see if I find something.
I ran additional tests, and it looks pretty much the same as you described
Nothing obvious in gizmo code
I’m not super experienced with Chrome profiling tool.
It looks like from my capture that it might be related to inputs.
Do you see something that might explain this behavior @PolygonalSun ?
Thanks for checking if inputs can answer these pikes in perf. If not, please reassign to me.
I’ll put some time on my calendar and take a look at things. I’ll have to figure out what’s inside of that function call around the time of that spike.
