Replace All performance could be greatly improved in a number of scenarios without too much difficulty since the exact higher-performing operation is already built into the existing application.
Replace All operations run far slower than necessary in some scenarios and the cause of the slowness should be easy to eliminate.
The generic description of what the cause appears to be is when each iterative replacement (or possibly batches of replacements) trigger some other operation to occur in the application that is far more expensive/slow to complete than the replacement its self, which causes the Replace All to run far slower than it should with no discernible benefit over running the same replacements without triggering the additional operations that are slowing it down.
There are probably other scenarios that can occur within the generic description above, but I will note the two specific scenarios that I run into with some frequency and have to work around:
- When editing as any form of text where line numbers are calculated and each Replace iteration changes the number of lines
- When a syntax highlighting template is applied (more specifics of what and how slowdowns are triggered are not known).
An actual specific example of scenario 1:
I have a file with roughly 250,000 lines of text with a short character sequence in the middle of each line that marks the start of content I want to split into the next line. After replacing the file will have twice the number of lines it did prior to the replacement. The find and replace inputs are Text with Regular Expression matching enabled. The Find is just simple, directly matched ASCII characters and the replace is just those same characters but followed by \r\n e.g. :00 → :00\r\n
When editing as Hex so that line numbering is not being calculated for any UI usage, the Replace All operation described above completes in 15 seconds.
Switching to editing as Text and running exactly the same Replace All operation causes the run time to balloon to 287 seconds, a 1800% increase in the run time of the operation!
While the line number issue is clearly the most significant, other UI interactions during the operation still cause some slowdown, and the same file with the same replacement through a Replace In Files operation completes in 6 seconds. I would take a greyed-out document view and a “Replace All in progress” or some such message to turn 287 seconds into 6 seconds any day.
I don’t have a specific list of what templates and/or highlighting causes slow-downs in replace-all operations, and what I have seen is much less severe than the line-count-altering replacements in text editing mode, but one specific example I can cite is a 25 MB xml file with a replacement that changes nothing syntactically but inserts line breaks before each tag opening and closing with < replaced with \r\n<
With syntax highlighting off it took 139.5 seconds, and with it on it took 180.25 seconds, and 29% increase.
Sadly I sometimes end up just closing a file, putting it in a folder by its self and doing a Replace in Files operation as the quickest way to avoid a replace operation getting bogged down by it being loaded and presented in the UI, but that fact points to a simple, pre-existing what-to-do example already built into the application.
If there could just be a search option that would treat documents opened in the UI the same as ones undergoing replacement as part of a Replace in Files set (i.e. progress bar in bottom status bar and Replace Results output only) instead of doing all the additional operations that are done when the document is opened, that would be ideal to address performance without disrupting usage for anyone that prefers the status quo.
At least personally, I think the progress bar in status bar at the bottom of the window combined with the orange lines on the left side of the Replace Results pane are the only really useful feedback when a Replace All is in progress, and presumably many if not most users would gladly give up some of the UI updates in exchange for faster Replace All operations, but adding it as a search option lets anyone that wants to keep the exact current updating scheme do so if they wish.