ST4 save of many files is slow compared to ST3

[RayLargo]

Description of the bug

The replace-in-files is very slow in ST4 when compared to ST3, in a range of 120'' to 2' for the biggest task used for testing.
The delay appears is in the saving of the files opened for the replacement:

• ST3 UI freezes, but finishes very fast
• ST4 UI does not freeze, you can see both the name of each saved file in the status bar, and the change of the "save pending" dot to the "saved" cross in the file's tab or "Files list" sidebar. But it is very slow (>120' for the 7.000 files test).

Steps to reproduce

Replace-in-files \A(.) with \1 in about 7.000 files that are thus opened. Select File - Save all. About 2' in ST3, >120' in ST4 in my setup.
My files 1-byte-character text in Windows 1252 encoding, totalling about 7 million lines

Expected behavior

ST4 as fast as ST3 in saving

Actual behavior

ST4 very slow in comparison, as described above

Sublime Text build number

4126 for ST4, 3211 for ST3

Operating system & version

Tested in Windows 11 and Windows 7

(Linux) Desktop environment and/or window manager

No response

Additional information

The ST3 is my usual one (licensed, updated). The ST4 is a new install. I ran the ST4 tests in normal and safe mode, with no difference.

The tests have been performed in two workstations, a new Windows 11, 16 core, 32Gb. And the previous workstation, Windows 7, 8 core, 16Gb.

In both, same test (ST3 and ST4), and the results are the same (in the Windows 7 machine both tests run slower than in the Windwos 11 one, but ST4 very much slower than ST3 on both).

OpenGL context information

No response

[deathaxe]

Maybe a timer can be used to update status bar messages with an interval of 1 second, so not each saved file is printed individually.

[RayLargo]

That sounds as a possible solution. If a FIFO with the return status of the multiple saving-worker's has been used, and the FIFO is used for a one-by-one report by the UI-thread ...

[RayLargo]

I wondered if this is an enhancement, as marked, or a bug, as it makes ST4 certainly lose one very useful feature of ST3, the lightning-fast find-replace-save-close cycle on thousands of files.

One second though about the timer idea: if a FIFO is used for the receiving the "work done" message of the threaded workers, then a simpler "count modulus 100" may be used for emitting just a fraction of the status updates ...

[BenjaminSchaaf]

From my testing on Linux ST4 is about as fast at fully completing the replacement, but ST3 will create the tabs and be "responsive" (it lags a whole lot but is still interactive) while the replacements are completed in the background. There are some improvements for this in the works, though really a proper solution that doesn't force every file to be opened in ST would be ideal.

[z-aki]

running into this.. It's saving 3 files per second. For 5k files it's a lot..

attaching a sample stack trace while sublime was unresponsive.

code-stdin-gEd.txt

build 4173

[deathaxe]

I can confirm ST being quit slow when mass saving files especially on Windows.

Steps to Reproduce

1. create a folder
2. copy content from e.g. /usr/share/zsh/functions/ from any Linux distro (e.g. Debian 12)
   These are round about 1200 files.
3. open that folder in a vanilla ST
4. open find in files panel and enable regexp mode
5. paste
   • \A((?!#!).+\n) to "Find:" field

   • #!/usr/bin/env zsh
     \1
     

     to "Replace field"
6. perform the search
7. perform "Save All"

Expected Behavior

The overall size of saved files is 17.6MB. On a fairly modern SSD with 4GB/s write speed, files should be saved nearly instantious. With given OS overhead, maybe few seconds.

Actual Behvior

Saving all files takes about 2 minutes.

My first hunch was it being related with printing status bar messages, which may slow down asynchronous / parallel? saving of files.

A closer look on Task Manager however revealed SSD being constantly utilized with about 60MB/s over the whole 2mins.

Procmon trace finally revealed session file being saved between each file save operation. This means, the whole session file (about 2MB of size) is saved about 1200 times in this special case.

Depending on session file size and amount of files to save, the overall process is significantly slowed down.

FWIW, ST4200, Windows 11, Windows Defender disabled

Suggestions

1. Save session file once, before starting (to avoid loosing unsaved changes in case of a crash) and once after all files have been saved.
2. Don't display each saved file, but specify an update rate and display only those files which are currently saved at such ticks. If thousands of files are saved, it is impossible to follow status text anyway.

[BenjaminSchaaf]

@deathaxe thanks for finding that, we've got a fix in the works that should speed things up considerably.

Just to set some expectations: Files are always saved one by one with fsync to ensure things are fully written and all possible errors are handled. Unfortunately this does slow things down considerably. From profiling if you don't have any plugins >90% of time is spent doing file saving IO (after the fix). With very small files I'm not seeing above 20MB/s doing this, 120MB/s with larger files. (this is on Linux, which generally has faster IO)

[deathaxe]

Reads great!

Given my example consisting of just 11MB of size, 20MB/s would result in 0.5s for saving them. That's very ok. Even some seconds are acceptable.

May I additionally suggest to limit update rate of status bar messages or even just provide a stat like "[523/1232] files saved" as no one can follow those quick messages, if a certain ammount of files to save is exceeded?