Besides the question of why only the freeze when sorting by Date Modified, there is another aspect to this problem.
In the workspace that I sent you, there are a total of 31625 files.
So if I type 1 letter in smart open, even with a local file system, the number of files containing that letter will be very large. Will SE be scanning for the dates of this large subset of files before allowing a 2nd character to be typed in? Even with a local file system, scanning for the dates of up to 31625 files can take a very long time.
I think the Smart Open should be scanning the dates in the background to allow to type in multiple characters, chances are I'm going to type multiple characters, so why waste CPU and waiting time scanning files containing 1 character when another character will surely be typed in?
Also, I have only 56 files that match "main.cc" out of the 31625 total in the workspace. I wrote a script to perform "ls -al" on ONLY these 56 files, it takes less than 1 second, even with all these 56 files on the remote file system. So there is no reason Smart Open should be freezing when I do: 1. Smart Open without "Date modified" column, 2. type "main.cc", 3. Turn on "Date Modified", 4. Sort by "Date Modifed", 5. Click on one of the main.cc, 6. SE freezes. Why is SE freezing when it takes only 1 second to scan these 56 files?
So I think the Smart Open is performing a date scan on many many more files than needed, especially as each character is typed in, but also when only the 56 main.cc files are displayed, I suspect SE is scanning dates for much more than these 56 (even with main.cc in the edit box), and doing this in the foreground freezing SE.
But also, even when just the 56 files match the main.cc and are displayed in the smart open tool window, I suspect that SE is performing a date scan on many more than just these 56 files when I click on one of the main.cc, SE opens this main.cc, and then I think SE is scanning for the date on many more files than just these 56.