Sublime Forum

Regex find and replace often absurdly slow- is not an important feature?

#1

Is find and replace just not an important feature in sublime?

I work on data files a lot, which often involves extensive restructuring of files using regex.

I can completely lock up Sublime by doing something trivial like adding/removing line breaks in a smallish file, such as 3mb. Sometimes it will complete the job, sometimes I have to kill the program. This is on my work dev system, a macbook pro with a 3.1GHZ i7 proc and 16gb of ram, so, I doubt it has anything to do with lack of horsepower. Files larger than 10mb are typically a complete waste of time, I have given up trying. This was a problem with the previous version, and it hasn’t gotten much better with version 3.

I know the line breaks example is one that trips up most editors, but it’s a good example of how to strangle sublime.

I have found I can usually remote into my desktop at home, transfer the file across, complete editing the file (more than one find and replace), and transfer the file back long before sublime has returned to usability from just a single find and replace. And that’s on an eight year old PC, and using EmEditor.

0 Likes
#2

Can you provide an example file and an example search and replace query that should exhibit the slow behaviour you describe?

0 Likes
#3

You should try disabling highlighting of matched results. It’s a button in the Find panel. It is known to cause bad permormance with large files though I never had such significant slow down as you are describing with even larger files.

0 Likes
#4

Sure, an example- here’s the query, to replace new line with BBB:
\n
replace with
BBB

File is 22mb, 530,000 lines.

I started the ‘replace all’ at 11:42 AM, it’s 12:01 now, still spinning. The same F&R on my home PC took @30 seconds.

Once it recovers/crashes, I am going to try again, but using FichteFoll’s suggestion of disabling the highlighting of matched results.

0 Likes
#5

Hmm. I am unable to disable the highlight function.

I added this to the Preferences.sublime-settings User file, saved, and re-opened sublime- the setting was retained:

“match_selection”: false,

‘chars’ in the “Find:” box highlights the first instance of ‘chars’, and puts the outline around all the others.

0 Likes
#6

If you do a little experiment you’ll find regex is lighting fast, unless you are replacing newlines. I think forming big lines is part of the issue too.

0 Likes
#7

Well, I don’t know what experiment you might mean, but I am here because I work on files doing regex find and replace on a regular basis, and I can’t believe a program that costs as much as this handles this so poorly.

The program regularly goes off into thinking-about-it-land, which means I can’t work on any other files until it stops, and often it locks up. I can lock it up queries other than a new-line-replace, that was merely an example I knew would do it for sure.

If I am the only person having trouble with this, then it’s probably my issue, I can accept that. The experiment I ran yesterday locked up Sublime, I had to kill it. The same task took 30 seconds in EmEditor on an 8-year-old PC.

0 Likes
#8

I hate to be the pedantic guy, but you still haven’t provided an example file that showcases the problem. Can we generate it ourselves? Is the problem like @nutjob2 describes in replacing newlines?

If you replace newlines with BBB, you’ll get a single really long line with a bunch of BBB characters dispersed in that one long line. It is known that Sublime renders long lines poorly. It could be that the problem is in actually displaying that line, not in the regex replacement functionality.

1 Like
#9

OK- that’s an excellent point. Here’s an example file which breaks just the same.

https://drive.google.com/file/d/0ByGcEgRA1stST1ItUnlZb25TWjA/view?usp=sharing

So, if displaying the find and replace of a new line is the problem, then using find in files and disabling the preview should circumvent that.

I have locked up Sublime twice in a row testing that with this file.

0 Likes
#10

This is just a guess, but it may be re-evaluating the (newly created, longer) line each time you replace the newline, and performance may not be linear with line length. I think a lot of what ST does, like syntax highlighting or definition referencing, is line oriented and the regex implementation is largely line oriented or optimized. So each time a line is concatenated it may be running large numbers of regexes against it.

So the takeaway from that thought bubble is that you may want to:

  • make sure syntax highlighting is turned off
  • try to fashion a regex that doesn’t cause the line to be re-evaluated (probably tricky)
  • try and not create very long lines (I’m guess that is not practical for you)

Because of your particular needs you may be better off using a different tool doing this particular kind of regex replacement, it seems that it just happens to clash with everything else ST does.

1 Like
#11

I’ll give it a whirl, thank you for your help and thoughts on the issue.

0 Likes
#12

For such a large file and for performing more of a batch operation than interactive code editing, you’ll be better off with a command line editor. Here’s a fair looking comparison of these kinds of operations in different editors. Sublime does well against similar, interactive, GUI editors, but is crushed by its keyboard-only bretheren:

If you’re on a Mac, BBEdit is a GUI editor that historically has been really good with huge files.

1 Like