SE 27.0.2 very slow to list project files and open buffers

[rajkej]

I just updated to SE 27.0.2 on MAC ARM build. Sometimes when I open the list of project files (project-load command keybound) or list open buffers (list-buffers command keybound), I get the MAC spinner for about 5 seconds before the window opens. If I close and then reopen those windows within a short amount of time, I don't get the spinner. But if I wait a while (not sure how to define this more accurately right now) then the spinner returns.

This is different/new behavior than 27.0.1. My projects have 3K-5K files in them. I usually have less than 10 buffers open at a time.

The profiling output (attached) seems to indicate to me that filelist_activate_tab and activate_tool_window take about 5 seconds sometimes. Let me know if there is something I can try to help alleviate this issue I'm having. Thanks!

[Dennis]

Did you happen to save those profiling results so I can sort through them more?  Are the files local or remote?

[rajkej]

I did not save the results but I can replicate them next time I'm in the office (Tuesday 2nd). The slickedit files are local (.vpj,etc). The source files are remote.

I created the project in 27.0.1. I do not use the wildcards method, I add files to the project by tree.

[rajkej]

Here is a saved profile. I opened SE, re-tagged the project to make sure the network files were responding, then started the profiler and tried the list project files command via my keybind. It took several seconds. Then I saved the profile.

[Dennis]

It does seem to be taking a long time to update the tree.  Do you have the Files tool window docked or floating or only set up to open on-demand?  You could try docking it (or dock and auto-hide) so that it does not have as much work to do every time it comes up.  I also see one area where it might be inefficient.  I will look into that.

[rajkej]

If you mean the project list files tool window then I have it in its default state where it is not docked or showing, it shows when I run the project list files command.

Please note that 27.0.1 does not have this issue. Also note that sometimes when I open the list buffers window that I get the spinner with 5-second wait. I think something changed from 27.0.1 with hot fixes to 27.0.2 without hot fixes that is causing this delay.

[Dennis]

I'm referring to the Files tool window.  Same tool window comes up for list-buffers and project-load command, just focused on a different tab.  I am going to put in a minor fix that will help some, especially with list-buffers.

I would recommend docking the Files tool window.  To do this, you'll need to bring it up, right click in the title bar, and check "Dockable", then drag it to dock where you want it to live.  I like to dock it with the "Defs / Projects / etc" tool windows.  Having it docked eliminates the need for it to rebuild the file list every time you use it.

You might also want to consider re-binding your list-buffers command to use document-tab-list-buffers.  This will simply activate the drop-down on the document tabs, and is slightly faster than the Files tool window.

[rajkej]

I went ahead and docked the files window as mentioned. I still get the spinner and 5s delays whenever I keybind to that window or click on it. Whatever is going on has not been helped by the docking.

[Maximus]

I also see this issue after upgrading to v27.0.2.0 (v26 still works fine with the same project files!)
I get constant freezes of SlickEdit when loading workspace and after that each time I do something with 'Files Tool Window' (e.g. filter files there). The slowness is huge for my ~70K files project - for example loading project might take 1-2min. Every time I type character at 'Files Tool Window' I have freezes of 10-20 seconds per character (while editor filters the list of files)

Few more inputs I have:
1. I'm using Mac ARM version on M1
2. Source files are remote, project files (vpw,vpj,vtg,vpwhistu) are local. NOT using Wildcard (adding 70K files as a list when creating project)
3. Issue DOES NOT happen when using local source files added with wildcard (.wildcardcache)
4. 'Files Tool Window' is docked and I'm using 'Workspace' tab where I filter files that I'm looking for

Just found a workaround that allows me to continue my work: File Options->Open->Maximum number of files to list = 20 (default is 5000).
This truncates the list of files at 'Files Tool Window' to 20 and make this window responsive. But it limits the list of files I see which is a significant limitation for my work.

[Dan]

Is there an amount in between that works better?  File Options->Open->Maximum number of files to list = 1000 would insert 20% of the data but still put in far more of the files.

[Dennis]

Try this:  Right click in the Files tool window (Workspaces tab), and change the setting for "Show relative paths".  Maybe calculating relative paths (or calculating absolute paths, depending on your current setting) is dragging down performance for you.

[Maximus]

"Show relative paths" enable/disable doesn't make any difference for me.

File Options->Open->Maximum number of files to list = 1000 causes freezes around 3-7 seconds for me, so it's not an option. Value=50 is the limit for my nervous system

Previous version of editor filters the files instantly without any latency while I'm typing at "Filter" field (with Maximum number of files to list = 5000 setting and 70K files)

[Dennis]

Both of you have remote source files.  What sort of remote file system?  Windows/SMB, NFS, some form of cloud storage?

[Maximus]

Remote OS: Linux

Local OS: MacOS with SSHFS
SSHFS_MOUNT_POINT located at /Users/<username>/kishon  (looks like a regular directory drwxr-xr-x@)

Source files are added to .vpj as below:
<F N="../../kishon/file1"/>
<F N="../../kishon/file2"/>

"Files Tools Window" shows them as below:
file1  |  /Users/<username>/kishon/file1
file2  |  /Users/<username>/kishon/file2

Since you mentioned calculation of the relative path that might slow down things, maybe in my case it's the evaluation of  '../../'  as  '/Users/<username>/'

[Dennis]

Just an update:  I was able to reproduce this issue and have identified the change that caused the problem.  I am putting together a fix.