There have been other reports on the forum about that, and I can attest it has been happening for many versions.

I have a “junkpile” drive with a dedicated drive letter. It has about 1 000 files of numerous types, including 100-200 torrent files, and two dozens of sub-directories of varying sizes and numbers of files. As you may guess, I sometimes add those torrent files to Tixati. If this drive is the current (last) location for adding files, interface hangs for about 5 seconds after clicking the plus button, then it shows the dialog window, then draws its elements. During that, 1 CPU core is busy with Tixati process (mostly in kernel, as Process Explorer shows). I can hear HDD getting really busy the first time it happens, but later attempts (with data presumably cached by the operating system) still take similar time to hang.

Process Monitor shows that Tixati (more likely, SHELL32 & friends) makes about 1 000 000 (!) registry operations with paths like
HKCU\Software\Classes\.pdf
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.jpg
and so on, checking the types/GUIDs/icons/whatnot of each file found in drive root directory. It also queries .torrent files (multiple times) and, for some reason, .zip files (maybe built-in ZIP shell extension wants something from those). It also runs verclsid.exe multiple times, which also hints that shell extensions get loaded. It also figures out default icons for drives, folders, special folders like “My Documents”, and so on. Combined, it results in a multi-second delay.

Interestingly enough, if I choose some other directory on that drive, even an empty one, it STILL enumerates all files at the root of the drive to show an empty directory, but only makes about 500 000 operations, and finishes a bit faster.

Setting the last directory to a path on a different drive with little or no files at root makes the window appear fast enough. Setting it back to a populated drive restores the hanging.

To be honest, I would prefer basic file and folder icons if it stops that nonsense with running most of Explorer under the hood to show a list of files without providing any shell functionality whatsoever. Moreover, there seems to be absolutely nothing one can do there but to select one or more torrent files, so what's the point?

My other, “too educated for his own good”, guess is that the combination of Tixati code and shell component code created file enumeration approach of quadratic complexity. This explains why such a small change in file quantity (say, 10 to 1000) results in significant delay. Some unlucky fellow with 10 000 or more files peacefully lying around somewhere might not even wait long enough to see that window, and, well, there was a bug report just like that.

Seems to me like a plethora of overthinking. "Too many files on disk" is obviously the problem IMHO. So stop overfilling your disks. Problem solved.

It has never been good practice to fill any disk to the brim. Ever.

You're missing the point. The disk is not "filled to the brim". It simply contains many files. Could happen with a C drive Windows, for example: the Windows folder on my current system holds 10% on disk space but 300k files.

You probably didn't notice the number. A thousand files is not “many”. It could be in 1990 — and only on some systems, — but certainly not today. Moreover, the effect is the same for any directory on the same drive, even completely empty one.

For comparison, sources for a big project (like a web browser) can spread over 100 000 files (across many many subdirectories). While not everyone is expected to wrestle with tasks like browser compilation, it would be wrong for some program to consider such number impossible, as examples like those are readily available. Professional usage can also generate similar big data sets.