New subject: [Bug 39773] File->Open slowdown caused by desktop.ini checks

10 Dec 2015


      https://bugs.winehq.org/show_bug.cgi?id=39773
Bug ID: 39773
           Summary: File->Open slowdown caused by desktop.ini checks
           Product: Wine
           Version: 1.8-rc2
          Hardware: x86
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: shell32
          Assignee: wine-bugs@winehq.org
          Reporter: fgouget@codeweavers.com
      Distribution: ---
To reproduce this you will need two Linux machines, a Samba server and a Samba
client.
On the Samba server:
* Create a directory with lots of subdirectories and files:
   mkdir smbdir
   cd smbdir
   for i in `seq 1 200`;do mkdir sub$i; done
   for i in `seq 1 200`;do touch file$i; done
* Export smbdir through Samba. (alternatively you could export '/' and use
'/usr/lib' as a replacement for smbdir)
On the Samba client:
* Mount the Samba share. You can either do it by adding a /etc/fstab line like:
  //MYSERVER/smbdir /mnt/smbdir cifs
rw,username=MYLOGIN,password=MYPASSWORD,domain=MYDOMAIN 0 0
Or by starting Nautilus in GNOME, clicking on '+Other Places' -> Windows
network... using GVFS. Note that in this case you'll have to work around the
colon in the mount point filename (see bug 34868).
* Slow down the network connection using a command like this:
   tc qdisc add dev eth0 root netem delay 10ms
* Check the above line is effective by running:
  ping MYSERVER
  The rtt should be around 10ms.
* cd /mnt/root/
  wine notepad
* Open the File->Open dialog, navigate to the smbdir folder exported through
Samba.
* BUG: The initial display will be slow and scrolling through the many
subfolders will be very slow.
* Change the file mask to '*.*'.
* Scroll all the way to the right so only files are visible. As long as only
files are visible scrolling should then be very fast!
* Finally change the rtt to 0ms on the Samba server and check that the RTT is
under 1ms.
* Now test again notepad's File->Open dialog and everything should be
reasonably fast.
The problem is that whenever File->Open displays a folder in the open file
dialog it checks whether it contains a desktop.ini file to display the right
icon. That's not cached, thus incurring a few file lookups per folder
displayed. For local file systems that's fast enough but on network shares with
a non-trivial RTT the speed impact is significant. A 10+ ms RTT makes the
dialog essentially unusable.
Note that when displaying a filename we have everything in the cache so
redisplays are lightning fast and track the mouse.
Also Microsoft Office has the same problem even though it does not use the
standard comdlg32 dialog (though that may depend on the Windows version being
emulate). On Windows Microsoft Office suffers no slowdown in this situation.
What this means is that the standard common dialog is probably the wrong level
for fixing this.
Hacking SHELL32_GetCustomFolderAttributeFromPath() in shell32 to just return
FALSE speeds things up greatly. The display still lags a bit behind the mouse
so that there may be some residual file lookups or other slowdowns but it's
still night and day.
-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 39773] New: File->Open slowdown caused by desktop.ini checks