Web/UI Start is extremely slow if you've used the output gallery a lot in the previous session

[one-lithe-rune]

The process of cleaning up the gallery files created in shark_tmp can be very slow, and its not obvious what is happening while it is doing the cleanup.

This is a nasty combination of Gradio creating lots of zero length and duplicate files in many subdirectories for galleries, especially in the 3.22.0 pinned version we are using (gradio-app/gradio#4256 supposedly fixes this in 3.32.0 and later) and python's shutil.rmtree being very slow for various reasons.

I'll add something that prints out what is happening, and try a different method of removing the subdirectories and files, but I need to check that actually helps before going ahead with a PR.

Putting this issue up in case it doesn't, or doesn't help enough, and to record the gradio issue.

[one-lithe-rune]

Okay, looks like the shutil.rmtree slowness is not a thing in recent python versions.

The problem is mostly down to gradio creating those zero length files, which in the 3.22.0 version it does for every image in a gallery every time that gallery is loaded or updated. 😬

[powderluv]

yikes. thanks for digging into it. We pinned to 3.22 for some transient breakage. We can try to unpin to the latest.

[one-lithe-rune]

PR with a workaround, on the assumption we need to keep 3.22 pinned: #1531

[one-lithe-rune]

I was using a more recent version of gradio recently to try and get gradio's version of HMR working (I kinda sorta got it working but I decided it wasn't very useful in a multi-tab environment), and that did cause some breakage. Most immediately the randomize buttons stopped working, so if we did upgrade it would need some attention.

[powderluv]

3.22 has some security vulnerabilities so we have to update now . @Shukla-Gaurav fyi in case you can do it as part of your changes

[one-lithe-rune]

Closing now #1548 has been merged.