Feature Request: Parallel Processing (Multithreading)

[Harry Brookes]

@gstavi said in Feature Request: Parallel Processing (Multithreading):

A single CPU has enough power to handle your keyboard typing.

“640K ought to be enough for anybody”

Only 3 years ago but someone with similar foresight to half a century ago.

There’s always someone there to explain why something hasn’t been implemented yet, rather than questioning “why not?”

Some of Notepad++ users use it as a reverse engineering tool and when running “Find in files” (great feature) which is extremely slow in comparison to even a 10 year old mobile phone (yes lecture me on architectures or if I’m lucky why a reduced instruction-set computer outperforms x86 at this task that’s 10 generations ahead).

The team at Notepad++ are amazing for their contributions and development of this app but comments like yours only stifle development. 8 people boosted up a comment because they don’t need it themselves… So the people who ask for sensible 21st century advancements get pushed to the side.

Your comment started with “Most of us”… I’ll answer that "All of us will benefit from multi-threaded workloads…

If they can support 32-bit builds which next to none of us use a 32-bit computer (which even then they have multiple cores)… Then asking for multi-threading support on a find and replace really isn’t asking a great deal, is it?

[Harry Brookes]

@ThosRTanner I’ve just achieved multi-threaded find and replace in a simple Powershell script using 1 thread per directory before moving onto the next job.

I think it’s simpler when people don’t try to find reasons for things being harder than they actually are.

Powershell is one of the most primitive “high-level” languages around and it was much faster.

Of course a pretty GUI with better ease-of-use is much more preferrable :)

[Mark Olson]

@Harry-Brookes said in Feature Request: Parallel Processing (Multithreading):

I think it’s simpler when people don’t try to find reasons for things being harder than they actually are.

People constantly insist that the single-threaded nature of most core Notepad++ APIs must just be due to sheer laziness on the part of its core devs, and those people have apparently never actually looked at the codebase and tried to understand the issues involved. Refactoring anything in NPP to use multiple threads is (by my estimate) several times more difficult than creating a multithreaded version of the same thing from the ground up.

Notepad++ has a tremendous amount of shared global state, which could only be made compatible with multithreading through extensive use of mutexes, which would then introduce dramatic performance losses in single-threaded use cases (at best) and deadlock (at worst). By the way, have you ever tried to debug a multithreaded program without extensive use of log files? Hahahahaha, good luck.

Find-and-replace in files seems like an embarrassingly parallel operation (or at least one that can be achieved with only one or two mutexes), but the devil is in the details, and as someone who has actually read the source code for Notepad++'s implementation, there are a lot of details there.

EDIT: AFAICT, the simplest way to even begin to implement multithreaded find-in-files in NPP would be to use multiple Scratchtillas (NPP uses _pscratchTilla as a lightweight way to run Scintilla operations like find/replace on a file without doing any graphics rendering), and use some simple task-dividing/scheduling algorithm to decide which Scratchtilla works with which file. The scariest problem that I can think of comes when the the Scratchtilla has to report its progress back to the form that shows progress. From my limited experience (I am admittedly a noob to multithreading with GUIs), there seems to be a lot of risk of deadlock whenever multiple threads contend for a lock on a GUI element. And that’s just the tip of the iceberg.

[Harry Brookes]

@Mark-Olson Embarrasing to yourself but maybe not for people wanting to reverse engineer 100,000s of files to find matches.

[Harry Brookes]

@Mark-Olson To use Scractchtilla is a useful insight. Ive used external tools that I’ve automated to get multithreading capabilities.

At least me mentioning here, opened up the topic.

Rewriting the entire NP++ project is no doubt not viable. I won’t accept from anyone here that there isn’t a way to make plugins etc capable of utilising multithreaded ops.

Maybe my reasoning for using NP++ is different to other users in the forum… It’s only one tool in the toolbox atm.

I’ve used simple tools to find n search through 100,000s of files (that always becomes a “Not Responding” NP++ instance… To get the job done.

NP++ is still in my toolkit. I was only suggesting improvemeents.

“It can’t be done” - It doesn’t sit right with me

[PeterJones]

@Harry-Brookes said:
“It can’t be done” - It doesn’t sit right with me

He didn’t say that. Two years ago, he said “the devil is in the details”, which means it’s a pain to get it right, not that it can’t be done.

I won’t accept from anyone here that there isn’t a way to make plugins etc capable of utilising multithreaded ops.

Again, putting words into people’s mouths vs what they actually said, two years ago. I cannot find any claim above that plugins couldn’t do multithreading.

And, in fact, in that intervening two years, @coises has created the Search++ plugin, which is trying, among other things, to add multiple threads (at least for Find In Files). You might want to try that plugin, and see if the FiF performance is better for you there… That discussion is still active, so if you have specific feedback, that would be a good place for it.

[Coises]

@harry-brookes , @peterjones

“the devil is in the details”

And there are more details than I knew existed. The details have details.

It’s easy for a naïve multi-threaded implementation to be slower than a single-threaded implementation, as was demonstrated when @guy038 ran a test of my search on a folder on a USB stick.

I’m working now on improving it. It’s incredible how many ways there are to shoot yourself in the foot with multi-threading. I’ll feel validated if I can come up with something that is sometimes better than single-threaded and never worse than single-threaded. It remains to be seen if I can do it.

[gstavi]

Professionals who search 100,000s of files with Notepad++ are not professionals.
Professionals, when they reach that scale (and long before), use command line tools. Then they open the found files in an editor. Possibly Notepad++.

Haven’t looked at Notepad++ code for many years and have no plans to do so anytime soon.
The main performance bottleneck of search in files was that every file was fully loaded into Notepad++, then its encoding was guessed. Probably with extra overhead as if this file is about to be displayed. Then its contents were scanned for matches as if it was regular search. Simple, elegant and SLOWWWW.

The #1 required performance optimization is to have “search files as utf-8” feature which is basically grep. Assume all files are utf-8 (or ascii or binary). Scan them with efficient buffer by buffer linear algorithm without loading the entire file to Notepad++. But this is a different new feature, not optimization of current search which is still needed by people who (for some reason) use multiple encodings.

The #2 performance optimization is probably asynchronous I/O before multithreading. Maybe with modern NVME drives this is less true than it used to be with spinning disks. Still true for search over network share.

Multithreading is 3rd priority. It is extremely unlikely with original algorithm and rather easy for search as utf-8.

But again, opinions of people who can’t mix and match the right tool for the job and insist that every tool should adapt itself to their selfish needs should not have much weight.

[guy038]

Hello, @gstavi and All,

I completely agree with both of your statements:

Professionals, when they reach that scale (and long before), use command line tools. Then they open the found files in an editor. Possibly Notepad++.

And :

But again, opinions of people who can’t mix and match the right tool for the job and insist that every tool should adapt itself to their selfish needs should not have much weight.

Best Regards,

guy038

[Coises]

@gstavi said:

(You replied to my comment, but I’m not sure this was directed to me. In case it was…)

Professionals who search 100,000s of files with Notepad++ are not professionals.
Professionals, when they reach that scale (and long before), use command line tools. Then they open the found files in an editor. Possibly Notepad++.

I don’t really care who is or isn’t a “professional.” I started working on Search++ mostly to experiment with some user interface changes to provide more flexibility, while also wanting to expose the enhancements (formulas, more complete Unicode support) I built into the search in Columns++ in a more general-purpose framework.

It’s all way too much to propose as a change to the base program. I’m hoping that eventually (there is much work yet to be done) it can be a practical alternative to Notepad++’s built in search for people who like the user interface changes.

So, along that line, my current phase of development is working on Find in Files. Because I don’t rely on Scintilla’s interface for regex searching (I use a separate copy of Boost::regex with custom iterators directly against the Scintilla buffer), I can skip Scintilla entirely when reading files from a folder.

The main performance bottleneck of search in files was that every file was fully loaded into Notepad++, then its encoding was guessed. Probably with extra overhead as if this file is about to be displayed. Then its contents were scanned for matches as if it was regular search. Simple, elegant and SLOWWWW.

That part I skip, except that I still have to work out the encoding. Right now I handle all three forms of byte order mark, and in the absence of a BOM I differentiate valid UTF-8 (including pure ASCII) from anything else — anything else being processed using the system default code page encoding.

I don’t yet handle files with an internal character set declaration (like HTML or XML), UTF-16 without a byte order mark, or legacy code pages other than the system default.

The #1 required performance optimization is to have “search files as utf-8” feature which is basically grep. Assume all files are utf-8 (or ascii or binary). Scan them with efficient buffer by buffer linear algorithm without loading the entire file to Notepad++. But this is a different new feature, not optimization of current search which is still needed by people who (for some reason) use multiple encodings.

I have part of this optimization (no Scintilla and no encoding conversion, just use the correct iterator for the detected encoding), but I still read the entire file into memory, because processing the full possible range of Boost::regex regular expressions without the entire text present would be very challenging (if not impossible). I gather grep is normally limited to line-by-line processing; that wouldn’t fit with what people expect from regular expressions in the context of Notepad++.

It has occurred to me that a future (probably far future) enhancement to my plugin might be to offer the RE2 engine as an alternative. Since it doesn’t backtrack, processing gigantic files without needing to read too much data into memory at once would be possible.

The #2 performance optimization is probably asynchronous I/O before multithreading. Maybe with modern NVME drives this is less true than it used to be with spinning disks. Still true for search over network share.

I’m still experimenting. My last public version (Search++ 0.6.3.1) uses memory-mapped I/O for files that are not remote, but further testing has shown me that has little-to-no gain over just sequentially reading the files into a buffer for either my NVMe SSD or an internal hard drive.

The next thing I plan to try is “decoupling” reading and searching. Right now each thread reads and then searches; there might be some gain from separating those (a reading pool pushing to a queue from which a searching pool pulls), though my experience over the past two or three weeks has shown me I can spend a great deal of time pursuing a theoretically better alternative only to have it make no real-world difference at all.

So far the most stubborn problem I’m up against is figuring out how many I/O operations to submit at once. An SSD definitely benefits from letting all cores hit it with requests at once. A USB thumb drive suffers from that, and can actually perform worse than single-threaded… except when the files are cached from just having been read before, in which case they act like an SSD. For a remote share, the optimal number of simultaneous requests probably depends on the current state of the network — something I have no real way to model and test.

If you happen to know of a practical, real-world implementation of Windows code that determines at run time how many simultaneous read operations to issue against whatever is hosting a given folder for maximum throughput, please tell me about it.

Multithreading is 3rd priority. It is extremely unlikely with original algorithm and rather easy for search as utf-8.

I’ve managed to get around 13 times the performance of Notepad++ native search on an SSD in a system with an i-9 9900K (16 threads). Some of that is probably due to avoiding the use of Scintilla, and some (I think most) to multithreading.

I am definitely not a “professional” when it comes to having a clue how to measure performance properly, though, so not too much should be made of any of it.

But again, opinions of people who can’t mix and match the right tool for the job and insist that every tool should adapt itself to their selfish needs should not have much weight.

Agreed about the “insist” part. It’s almost always more productive to learn about what tools exist than to whine about how the one with which you are familiar doesn’t work the way you wish it did.

Yet users’ complaints are how those of us who develop software learn about what might be useful. That doesn’t mean we always can or should give people what they think they want — they know what impedes or annoys them, not the best way to make it better — but it tells us where existing tools fall short. It’s up to us to design ways to fill in the gaps, though not always the way a non-programmer might have imagined it.