It's mainly to save time.

I don't remember exactly how long it took but I remember it being something like 30 minutes of purely waiting for the find / replace to finish on a 4 CPU core / 8 GB of memory machine. Memory wasn't an issue fortunately.

Why would there be a market for something like this?

Once in a while things come up where you need to make a surgical edit in a really large file and it could be in a scenario where time matters.

For example if you're doing a SQL dump -> import, technically you could have downtime during this process to eliminate any chance of data loss. Having to wait ~30min for a command to finish is painful.

I'm not saying to go off and make this product to sell but if such a tool existed and you positioned it at $39 or whatever, if it could eliminate half an hour of downtime for a business it pays for itself. Especially if the alternative is to muck around with hex editing the file.

If 100,000 people have this problem and 3,000 of them would pay for it that's $117,000. If you spent 6 months making a super polished tool that made it easy to know exactly what's being edit (or deleting lines, etc.) that's pretty appealing. Even if the sales were half that's still solid but it could also be 5x too, who knows. Maybe you can finish such an app in 3 months instead of 6, etc.. It's also an app that mostly feels like it could reach a "done" state with little maintenance since you're editing text files which is a well known topic.

I mean, if you knew you only wanted to find/replace on line 4, why not simply stop the search after the first match?

The syntax escapes me at the moment, but I'm quite sure I've used sed (or maybe awk?) in the past to do exactly that

As far as I know sed will still read and write the full file, even when you do a modification on a specific line. I've target deleted 1 line with sed and it took quite some time too.

There's a big difference between "quite some time" and 30 minutes, though. Of course sed needs to read the file and write it back to disk, but that's capped by I/O speed which is very high on modern drives - we're talking seconds for a file in the tens of gigabytes on the fastest SSDs, a very far cry from half an entire hour.

This was run on an AWS gp3 SSD EBS volume with 3k IOPS. It was a CPU optimized c6i.xlarge machine. The file in question was 200 GB.

I used "quite some time" because this happened months ago and I don't recall the exact time on the delete. I don't think deleting a line was any faster than doing a find / replace on 1 line. If sed is reading and writing the file in both cases I'd expect both to have the same performance.

Sed takes ages to remove a single line from huge files too.