I understand that focusing on N++ buffers, instead of on saved files on disk, is not really appropriate for your multithreaded approach !

You said :

I am more inclined to raise a warning box telling the user that some of the files to be searched are currently open in Notepad++, and the search results (and modifications, when I get Replace in Files done) will apply to the stored files, not to the edits in progress in Notepad++.

So, given, your constraints, I totally agree ! That seems the more simple and obvious solution, with a Cancel button in case some concerned and opened files are dirty, in current N++ session

On the other hand, you said :

I wonder if any of this works properly when users have multiple instances of Notepad++ open and the files are open in a different instance than the one doing the search?

I personally mainly use N++ in a N++ mono instance so I can’t speak properly of that case. But I agree with you that managing several instances must be a challenge for the Find in Files or Replace in Files feature !

Best Regards,

guy038

@guy038 said:

You can verify that, in the table, at that time, the Search++ and Multiplace plugins, unlike N++, did a Find in Files search on the saved files on disk and not on the N++ buffers possibly modified

Yes, that is a condition I have not yet addressed, and it is good that you call it to my attention.

I am more inclined to raise a warning box telling the user that some of the files to be searched are currently open in Notepad++, and the search results (and modifications, when I get Replace in Files done) will apply to the stored files, not to the edits in progress in Notepad++.

The way these searches work would make it difficult (probably not impossible, but difficult) to attempt to insert open document searches into the multi-threaded file-based search process. There are significant differences in how the two are implemented.

Do you see much practical application for searching the files in a folder, some of which are modified and not saved in Notepad++, merging the search of the unsaved open documents with the search of the unopened files on disk? (For replace I can see the value of skipping open files, as you might have tested the change on a couple files before choosing to apply it to the remaining files. If you already saved the files, you’d be applying the change twice; if you hadn’t saved them, you’d have a bunch of “File has changed, do you want to reload?” prompts to dismiss.)

I wonder if any of this works properly when users have multiple instances of Notepad++ open and the files are open in a different instance than the one doing the search?

@coises, I recommend that you read this GithHub thread about the multiReplace plugin, specifically my following two replies :

• https://github.com/daddel80/notepadpp-multireplace/issues/133#issuecomment-5478750061

• https://github.com/daddel80/notepadpp-multireplace/issues/133#issuecomment-5492407859

In the first post, I asked @thomas-knoefel if the Find in Files search could scan the N++ buffers rather that their equivalents on disk !

You can verify that, in the table, at that time, the Search++ and Multiplace plugins, unlike N++, did a Find in Files search on the saved files on disk and not on the N++ buffers possibly modified

And, in the second post, I verified that the attached new build, provided by @thomas-knoefel, do scan the N++ buffers, by default !

Could you implement such behavior and add an option to search on N++ buffers, by default OR on saved files on disk, like within N++ v8.9.8 and MultiReplace ?

TIA for your time and work on this topic !

Best Regards,

guy038

@Coises, you said :

So I’m wondering, if you happen to remember, whether you tested in the order you listed, or whether you happened to test Search++ first?

Well, since my previous tests were done in July 18, 2026, I don’t remenber exactly the way I used but I suppose that I first tested the native N++ search ! Thus, I decided to conduct a new series of tests. Of course, the results of the entire scan of my D: USB drive, are slightly different. Luckily, the number of matches and files containing the Fi string are identical between the Search++ search and the Notepad++ search

IMPORTANT : I updated Search++ to the last 0.6.5 version, before all these tests

So, this time, I first use the Search++ Find in Files dialog :

• I stop and re-start my W11 laptop

• I pluged my USB key

• I start N++

• I ran an entire scan of my D: USB key for the Fi string, using the Search++ plugin

=> I got 27,081 matches in 841 files of 1,772, in 2m 10s

• I close N++

• I unpluged my USB key

• I stop and re-start my W11 laptop

• I re-pluged my USB key

• I start N++

• I ran an entire scan of my D: USB key for the Fi string, using the native Notepad++ search

=> I got 27,081 matches in 841 files of 1,772, in 1m 21s

As you can see, no real difference between these tests and those of July 18 ! On the other hand, this time, the results obtained with the MultiReplace plugin are completely different. After a complete re-start of my machine

• I ran an entire scan of my D: USB key for the Fi string, using the MultiReplace plugin

=> I got 18,767 hits in 726 files in 1m 05s. Most of non text files are not scanned at all ?!

I don’t understand these huge differences ? I first suspected that I allowed this option in MultiReplace settings : File Search : Skip files larger than but this option is not set !

Thus, right after this post, I’m going to post to @thomas-knoefel for possible information !

Remark that this present post is saved on a different USB drive to avoid future changes regarding the number of matches of the Fi string !

To end, @coises, you said :

In any case, after weeks of running in circles, I think I will soon give up the fight to optimize performance and see what else needs work.

I totally agree with this wise statement !!

Best Regards,

guy038

@guy038 said:

Now, I did a test, searching in all files of my D: USB key, with :

The native N++ Find in Files dialog

The Search++ Search in Files dialog

The MultiReplace Find All in Files command

To be sure to process fair tests, I unplung my USB key, re-start my laptop completely, replug my USB key and starts a new N++ session, before running these three Find in Files operations, in turn !

I searched for the Fi string, with the Match case and the Regular expression options checked. I got :

27,112 matches in 833 files of 1,761 searched for the N++ Search Results panel, in 1m 37s

27,112 matches in 833 files of 1,761 files for the Search++ Search++ Results, in 2m 21s

27,087 hits in 835 file(s) for the MultiReplace Search results panel, in 1m 36s

I have been struggling with how to optimize the multithreading of my search for over a month now. Among other things, I’ve found that most everything I thought I was measuring wasn’t what I was actually measuring.

One surprise I only recently discovered was that even if I eject and unplug a thumb drive and then plug it in again. there is still a “first time today” cost in the time it takes to read it. Windows is persisting something and it is able to identify the same drive, even though it’s been unplugged. I don’t know the exact time, but Windows on my machine keeps it for more than an hour and less than 24 hours.

Running a particular test the first time I plugged in a particular USB drive I have, it took 8 minutes and 26 seconds. After ejecting the drive, unplugging it, waiting a moment, plugging it back in and running the exact same test, it took 20 seconds.

This drive appears to take whatever it is that Windows does once a day (?) exceptionally hard. Most drives don’t show anything so obvious. This is the only drive I have tested so far that uses FAT, so that could have something to do with it.

I haven’t yet tested whether rebooting is enough to reset the “once a day” penalty, or if it persists in something that isn’t lost in a reboot. It may have something to do with antivirus, though I haven’t yet proven any such thing.

So I’m wondering, if you happen to remember, whether you tested in the order you listed, or whether you happened to test Search++ first?

In any case, after weeks of running in circles, I think I will soon give up the fight to optimize performance and see what else needs work.

• Update to ICU 78.3 and use static linking for ICU. This is expected to fix problems some testers have had running Search++ on older systems or on minimal Windows installs (like Windows Sandbox). For most users there will be no functional difference between this version and version 0.6.4.

Note: There are five icu——.dll files in older versions of Search++ that are not used beginning with version 0.6.5; so it is best to delete the existing Search++ folder (or its contents) before copying, rather than copying the new folder over the old one.

Even though it seems most people never experience that bug, I still recommend upgrading at the next convenient time, so we will all be testing the same code. It’s always possible that I broke something else.

I am still working on improving the multi-threading for find in files. I’m also trying to decide how best to mitigate a problem wherein Search++ fails to load when a particular Windows redistributable library has never been installed on the system. More updates should be coming before too much longer.

All thoughts, suggestions, comments, criticisms, bug reports and raspberries are welcome, and thank you to everyone willing to give this jalopy a good work-out.

@M-Andre-Z-Eckenrode said:

@Coises

As you I recently reported an issue with Search++ in a new, separate topic, but I see that several others have reported various issues in this one (presumably, because it’s still a work in progress). I have a new issue to report, and thought maybe I should ask if you prefer that new issues get reported in their own topic (which is generally my default), or for users to just include them in this one. Do you care one way or the other?

Either way is OK with me. I suspect the moderators might prefer to keep discussion confined to this topic, though.

As you know, I recently reported an issue with Search++ in a new, separate topic, but I see that several others have reported various issues in this one (presumably, because it’s still a work in progress). I have a new issue to report, and thought maybe I should ask if you prefer that new issues get reported in their own topic (which is generally my default), or for users to just include them in this one. Do you care one way or the other?

@Coises said:

I might be missing something. Do you find that it is not obvious enough in the document window itself when lines are hidden (the horizontal lines where the hidden lines are)?

Thanks for your hint; I see, the mistake is on my side! I use a different background color and my eyes are getting older ;-) Therefore I did not see the lines between the text:
My configuration vs. Default theme:
/
Now I know where to look.

Good point. I will fix that — not necessarily in the very next release, but I will fix it.

I know you have a lot of topics on your list that are much more urgent. For me it is a ‘nice to have’. Thanks for your help.

@sevem47 said:

First of all thanks to your great work with this plugin.

Thank you for trying it and giving feedback!

• Using a docking dialog for different plugins they may share the same space in NPP. If Search++ ist not active, there is just an empty space that is visible for me. Other plugins have a graphical representation that, in addition to the balloon tip, show which plugin is active.

Good point. I will fix that — not necessarily in the very next release, but I will fix it.

• Using Search++ I learned about the possibility to show only certain lines in the edit window. Would it make sense to have a marker that identifies that only some lines of a document are displayed after applying Search++ commands.

I might be missing something. Do you find that it is not obvious enough in the document window itself when lines are hidden (the horizontal lines where the hidden lines are)?

They are about graphical topics that probably are just cosmetical questions.

• Using a docking dialog for different plugins they may share the same space in NPP. If Search++ ist not active, there is just an empty space that is visible for me. Other plugins have a graphical representation that, in addition to the balloon tip, show which plugin is active. Two images to show my point:
  /
• Using Search++ I learned about the possibility to show only certain lines in the edit window. Would it make sense to have a marker that identifies that only some lines of a document are displayed after applying Search++ commands. Something like the following filter symbol to mark that not all lines are visible:
  
  (the image is copied from Total Commander’s function ‘Synchronize directories’)

Just some ideas that would help me in using Search++.

@guy038 said:

I’m actually really surprised by Search++'s performance compared to Notepad++, especially when the search involves a complex regular expression. ( 0:16.36 vs 2:08.20 ! )

Please, note that the USB flash drive I used for my test is a fairly old one with a capacity of only 512 Mb, which may not be well-suited for multithreading and would explain the poor results with Search++

In any case, I assume you’re now confident in Search++'s overall performance !

I don’t entirely trust my own results. Why did my USB search in Search++ for the take longer than the search for a([^\r\n])[^\r\n]*b\1? Either the test data is erroneous or spurious, or Search++ is screwing up access to the USB in some way that’s causing it to “choke” and lose performance (what I suspect happened in your test). I’m still trying to work out how to avoid that happening without hurting the performance when reads are fast.

To the best of my knowledge, Notepad++ is entirely single-threaded. It’s only ever doing one thing at a time. An i9-9900K can run sixteen threads simultaneously. So for CPU-heavy workloads (complicated regex searches) with lots of files, it’s not at all surprising that a multithreaded approach could be almost eight times faster. Thirteen times faster running a([^\r\n])[^\r\n]*b\1 against an SSD is pretty satisfying, though. :-) I’m probably getting additional gains from using memory-mapped I/O and running Boost::regex directly against the data the operating system maps into memory, while Notepad++ loads every file into a buffer, and from there into an off-screen Scintilla, before running the search through Scintilla’s API instead of directly with Boost::regex.

It’s useful to have tests like yours. I won’t be able to test anywhere near all the situations that can occur. What happens when someone searches a OneDrive folder and not all the files are up-to-date? What happens when someone searches a drive that’s mounted over a VPN? What happens when the cat knocks the USB connector loose in the middle of a search? The worst case for all these is that the whole thing either crashes and takes Notepad++ down with it, or locks up and makes the user terminate Notepad++ with task manager — losing any unsaved work in progress. I don’t want to let that happen. I still have a lot to do to “harden” this against things that can go wrong.

And that’s not even starting with Replace yet.

Your tests are much more comprehensive than my simple test and yield some interesting results !

In particular, the comparison between Notepad++ and Search++ for searches on a USB drive shows that Search++ outperforms Notepad++, whether the search is complex or simple !

Indeed, we have :

Search++ 0.6.3.1 :

U:\Testing2           a([^\r\n])[^\r\n]*b\1  0:16.36  149,919 matches in 2,505 of 3,762 files (Regex): a([^\r\n])[^\r\n]*b\1
U:\Testing2 (repeat)  a([^\r\n])[^\r\n]*b\1  0:08.87  149,919 matches in 2,505 of 3,762 files (Regex): a([^\r\n])[^\r\n]*b\1

U:\Testing2           the                    0:24.84  445,907 matches in 3,342 of 3,762 files (Regex): the
U:\Testing2 (repeat)  the                    0:01.03  445,907 matches in 3,342 of 3,762 files (Regex): the

And :

Notepad++ 8.9.7 :

U:\Testing2           a([^\r\n])[^\r\n]*b\1  2:08.20  Search "a([^\r\n])[^\r\n]*b\1" (149919 hits in 2505 files of 3762 searched) [RegEx]
U:\Testing2 (repeat)  a([^\r\n])[^\r\n]*b\1  1:54.96  Search "a([^\r\n])[^\r\n]*b\1" (149919 hits in 2505 files of 3762 searched) [RegEx]

U:\Testing2           the                    0:31.62  Search "the" (445907 hits in 3342 files of 3762 searched) [RegEx]
U:\Testing2 (repeat)  the                    0:14.16  Search "the" (445907 hits in 3342 files of 3762 searched) [RegEx]

I’m actually really surprised by Search++'s performance compared to Notepad++, especially when the search involves a complex regular expression. ( 0:16.36 vs 2:08.20 ! )

Please, note that the USB flash drive I used for my test is a fairly old one with a capacity of only 512 Mb, which may not be well-suited for multithreading and would explain the poor results with Search++

In any case, I assume you’re now confident in Search++'s overall performance !

Best Regards,

guy038

@guy038 said:

Now, based on my test, have you conducted any similar tests of your own, and have you found that searching with Search++ also takes longer compared to the native search in N++ ?

I ran some tests this morning because I wanted to get a reference before I start testing changes to the multithread scheduling in Search++ — so I can verify that what is supposed to be better actually is better.

• This is Windows 10 Pro, 64 bit, running on a 2019 desktop with a Core i9-9900K and 32 GB RAM.
• D is an internal SSD. S is an internal HDD. U is a USB thumb drive. \\PEACOCK is another machine on the same local area network.
• The content of the folder Testing2 on each drive is the same. It’s a mix of 3,762 files in 228 folders, 591 MB total. Somewhere around 5% are binary files (dll, exe, png, etc.).
• For U, following your lead, I did a “repeat” running the same search immediately after the first; after that, I unplugged and reconnected the drive before proceeding to another test.
• I couldn’t conveniently unplug the internal drives, but testing showed no significant variation in successive trials on D, S or PEACOCK.

Some of these results are surprising. (I thought the hard disk would be noticeably slower than the SSD, and I expected to see a repeat of your experience with the USB drive.) I suspect that some specialized knowledge I do not have, and perhaps a more controlled environment, is required to measure performance meaningfully, so all this should be taken as anecdotal.

Search++ 0.6.3.1:

D:\Quick\Testing2     a([^\r\n])[^\r\n]*b\1  0:08.71  149,919 matches in 2,505 of 3,762 files (Regex): a([^\r\n])[^\r\n]*b\1
D:\Quick\Testing2     the                    0:01.44  445,907 matches in 3,342 of 3,762 files (Regex): the
S:\Testing2           a([^\r\n])[^\r\n]*b\1  0:08.91  149,919 matches in 2,505 of 3,762 files (Regex): a([^\r\n])[^\r\n]*b\1
S:\Testing2           the                    0:01.10  445,907 matches in 3,342 of 3,762 files (Regex): the
U:\Testing2           a([^\r\n])[^\r\n]*b\1  0:16.36  149,919 matches in 2,505 of 3,762 files (Regex): a([^\r\n])[^\r\n]*b\1
U:\Testing2 (repeat)  a([^\r\n])[^\r\n]*b\1  0:08.87  149,919 matches in 2,505 of 3,762 files (Regex): a([^\r\n])[^\r\n]*b\1
U:\Testing2           the                    0:24.84  445,907 matches in 3,342 of 3,762 files (Regex): the
U:\Testing2 (repeat)  the                    0:01.03  445,907 matches in 3,342 of 3,762 files (Regex): the
\\PEACOCK\Testing2    a([^\r\n])[^\r\n]*b\1  0:12.32  149,919 matches in 2,505 of 3,762 files (Regex): a([^\r\n])[^\r\n]*b\1
\\PEACOCK\Testing2    the                    0:07.07  445,907 matches in 3,342 of 3,762 files (Regex): the

Notepad++ 8.9.7:

D:\Quick\Testing2     a([^\r\n])[^\r\n]*b\1  1:53:64  Search "a([^\r\n])[^\r\n]*b\1" (149919 hits in 2505 files of 3762 searched) [RegEx]
D:\Quick\Testing2     the                    0:14.14  Search "the" (445907 hits in 3342 files of 3762 searched) [RegEx]
S:\Testing2           a([^\r\n])[^\r\n]*b\1  1:53.99  Search "a([^\r\n])[^\r\n]*b\1" (149919 hits in 2505 files of 3762 searched) [RegEx]
S:\Testing2           the                    0:12.42  Search "the" (445907 hits in 3342 files of 3762 searched) [RegEx]
U:\Testing2           a([^\r\n])[^\r\n]*b\1  2:08.20  Search "a([^\r\n])[^\r\n]*b\1" (149919 hits in 2505 files of 3762 searched) [RegEx]
U:\Testing2 (repeat)  a([^\r\n])[^\r\n]*b\1  1:54.96  Search "a([^\r\n])[^\r\n]*b\1" (149919 hits in 2505 files of 3762 searched) [RegEx]
U:\Testing2           the                    0:31.62  Search "the" (445907 hits in 3342 files of 3762 searched) [RegEx]
U:\Testing2 (repeat)  the                    0:14.16  Search "the" (445907 hits in 3342 files of 3762 searched) [RegEx]
\\PEACOCK\Testing2    a([^\r\n])[^\r\n]*b\1  2:11.36  Search "a([^\r\n])[^\r\n]*b\1" (149919 hits in 2505 files of 3762 searched) [RegEx]
\\PEACOCK\Testing2    the                    0:29.46  Search "the" (445907 hits in 3342 files of 3762 searched) [RegEx]

(The reason for using [^\r\n] instead of . is that Notepad++ and Search++ have slightly different definitions of . when “matches newline” is not in effect: like Columns++, Search++ excludes only the characters that cause a line break in Scintilla, new line and return; while Notepad++ also excludes four other control characters, FF, NEL, LS and PS. The . is noticeably faster, but it returns different results for Search++ and Notepad++, almost certainly due to the binary files in Testing2.)

Edit: Added local area network tests.

• Fix a pair of errors that caused incorrect results when characters outside the basic multilingual plane were used in a regex replacement string and when a capture group included invalid UTF-8.

• Fix problematic behavior for Show file in explorer on the context menu for the file list in the Search in Files dialog when the file list is large. The action could become sluggish or fail to complete and interfere with other activity.

• Handle absolute file paths larger than MAX_PATH in Search in Files. (They still won’t open in Notepad++, but there was no reason Search in Files shouldn’t be able to parse them.)

• Avoid “configuration file for this plugin was edited” when running multiple instances of Notepad++: only save when the last instance is closing.

Nothing exciting here, and hopefully no new bugs… just some particular fixes.

Apologies to anyone who downloaded 0.6.3 in the short time it was available. I chose a dumb way to detect the last running instance of Notepad++ that was bound to cause a problem sooner or later. In 0.6.3.1 it is replaced with a less dumb way.

@guy038 said:

FYI, during all my tests, the Autodetect character encoding option, in Settings > Preferences… > MISC, was checked and all the files, described in the P.S. section of my previous post, contain a Byte Order Mark ( BOM ).

Autodetect is irrelevant when a byte order mark is present: Notepad++ always honors byte order marks. The only time autodetect matters is for a file with no byte order mark that doesn’t appear to be UTF-8 and doesn’t have an internal indication (like an HTML file with a <meta charset> declaration) of its encoding. With autodetect off, such files will always be read using the system default code page. With autodetect on, Notepad++ runs some heuristic tests to try to guess whether the file uses a different legacy encoding.

When plugins access documents open in Notepad++ they necessarily use the copies Notepad++ has already loaded, so they “inherit” Notepad++’s encoding detection. The loaded copy will always be either in the system default code page (“ANSI”) or UTF-8. Notepad++ converts any document that isn’t one of those. (Any indication in the status bar other than ANSI or UTF-8 means Notepad++ has converted the document to UTF-8, and will convert it back to the indicated encoding when saving it.)

If a plugin accesses files on disk without opening them in Notepad++ — as Search++ does for Search in Files, and as it appears MultiReplace does when searching in files — it’s up to the plugin to sort out the encoding.

I’m not familiar with the code for @thomas-knoefel’s MultiReplace, but based on your tests, I suspect it doesn’t process UTF-16 correctly when searching in files. You could probably construct a minimized example and submit an issue if you were so inclined.

Now, based on my test, have you conducted any similar tests of your own, and have you found that searching with Search++ also takes longer compared to the native search in N++ ?

Comparisons looked fine at first. I was running regular expressions with a lot of backtracking against thousands of files on an SSD. Then things fell apart when I tried a network share.

Most of my testing has been “stress testing” rather than comparisons, but they point to the same problem. I understand the problem. Engineering a solution is taking some time.

Your tests, with the inclusion of re-running the searches, demonstrate what is happening quite well.

In the rerun tests, the files from your thumb drive were already cached by Windows. Those second tests show (roughly) how much time the actual searching took. (Notice that Search++ was faster there, because it uses multiple cores of your computer to search several files simultaneously instead of processing them one at a time.)

The difference between the first and second runs is (roughly) the time it took to read the files from the thumb drive. That is where the current version of Search++ is just plain doing it wrong. I naïvely supposed that Windows was smart enough to “serialize” access to a device, like a USB drive, from different threads in a manner sensible for the device. Alas, it doesn’t work that way. However many threads your computer can run simultaneously, they’re all hitting the USB drive with requests for different files at the same time. Not only is that not any faster than single-threading them, it’s actually slower, because the controller in the drive is dealing with “too many” requests coming in all at once.

The multi-threading I have works pretty well for an internal SSD. It also works if Windows has already cached the entire folder in memory. For everything else… it sucks.

I’m working on solving that problem now. It’s slow going. There are a lot things you can “get by with” when single-threading that just blow up under one condition or another when multi-threading.

You said :

There are limitations, not yet formally documented, to the way Search++ handles encodings for Search in Files:

1. UTF-16 files without a byte order mark are not recognized as such. (They’ll be misread as something else.)

2. UTF-8 files without a byte order mark that contain any invalid UTF-8 sequences will be processed using the system default (ANSI) code page.

3. Pure ASCII files are processed as UTF-8. (This doesn’t matter for Find, but I will have to review it when I implement Replace, since someone might include non-ASCII characters in the replacement text. I think there will have to be a user control to determine whether to promote ASCII to ANSI or to UTF-8.)

4. Files without a byte order mark that are not pure ASCII and contain any invalid UTF-8 characters are processed using the system default code page. No attempt is made to detect whether a different legacy code page is more likely to be correct, or is explicitly declared within the file.

Thanks for this extra information !

FYI, during all my tests, the Autodetect character encoding option, in Settings > Preferences… > MISC, was checked and all the files, described in the P.S. section of my previous post, contain a Byte Order Mark ( BOM ). Here is the list of all UTF-16 files of my D: USB key

    •------------•--------------------------------------------------------------•-----------------•---------------------•--------------------•
    |            |                                                              |                 |    Multi-Replace    |   Search++ / N++   |
    |    BOM     |                             File                             |    Encoding     |     Matches 'Fi'    |    Matches 'Fi'    |
    •------------•--------------------------------------------------------------•-----------------•---------------------•--------------------•
    |   FE FF    |  D:\Plane_0_UCS-2_BE.txt                                     |  UTF-16 BE BOM  |          2          |          0         |
    |   FE FF    |  D:\Planes_0+1_UTF-16.txt                                    |  UTF-16 BE BOM  |          2          |          0         |
    •------------•--------------------------------------------------------------•-----------------•---------------------•--------------------•
    |   FF FE    |  D:\862_x64\plugins\NppExec\doc\NppExec\NppExec_HelpAll.txt  |  UTF-16 LE BOM  |          0          |         31         |
    |   FF FE    |  D:\Plane_0_UCS-2_LE.txt                                     |  UTF-16 LE BOM  |          2          |          0         |
    |   FF FE    |  D:\862_x64\plugins\Config\npec_cmdhistory.txt               |  UTF-16 LE BOM  |          0          |          0         |
    |   FF FE    |  D:\862_x64\plugins\Config\npes_last.txt                     |  UTF-16 LE BOM  |          0          |          0         |
    •------------•--------------------------------------------------------------•-----------------•---------------------•--------------------•
    |            |                            Total                             |                 |  3 Files / 6 hits   |  1 File / 31 hits  |
    •------------•--------------------------------------------------------------•-----------------•---------------------•--------------------•

Notes :

• The correct results are reported in the last column

• My USB key also contains 49 UTF-8-BOM files ( EF BB BF ) correctly detected by all the search engines !

Now, based on my test, have you conducted any similar tests of your own, and have you found that searching with Search++ also takes longer compared to the native search in N++ ?

Of course, I can run more tests myself, but I imagine your tests would be more valuable and might, perhaps, give you some ideas on how to increase the overall search speed with Search++

I’m really curious to hear your own observations !

Best Regards,

guy038

@guy038 said:

I understood the small differences which occur in the MultiReplace search ( 27,112 - 25 ) matches in ( 833 + 2 ) files. But, I prefer, first, to study more closely the MultiReplace plugin, which is very powerful too and reply later to @thomas-knoefel. It concerns the encoding of 4 files which is not recognized properly and which occurs only when the Find in Files command is used. The Find All and Find in Docs commands, themselves, give correct results for these 4 files !?

As best I can make out, like Search++, MultiReplace processes searches against documents open in Notepad++ using the copy of the document that Notepad++ has loaded into Scintilla. (I can’t really think of another way it could be done.) That means that for existing files, Notepad++ has already determined the encoding and either loaded it as ANSI or UTF-8, or translated it to UTF-8. (Notepad++ never sets Scintilla to use any encoding other than UTF-8 or the system default code page; anything else is translated to UTF-8 and translated back on writing.)

So it’s no surprise that we’re both using the same encoding as Notepad++ for Find All and Find in Open Documents, because we’re just using the work Notepad++ has already done.

I think MultiReplace uses an invisible Scintilla to process searches in files. It could be that it hasn’t entirely replicated the labyrinthine logic Notepad++ uses to determine the encoding of a file (including the effect of Preferences | MISC. | Autodetect character encoding).

Search++ does not duplicate that logic either, but it approaches the problem in a different way. Rather than using an invisible Scintilla control, Search++ uses its customized version of Boost::regex directly on the data in the file buffer. So I never translate the file encoding to anything else. I do have to determine the encoding, though, as the choice of iterator for Boost::regex depends on that.

There are limitations, not yet formally documented, to the way Search++ handles encodings for Search in Files:

1. UTF-16 files without a byte order mark are not recognized as such. (They’ll be misread as something else.)
2. UTF-8 files without a byte order mark that contain any invalid UTF-8 sequences will be processed using the system default (ANSI) code page.
3. Pure ASCII files are processed as UTF-8. (This doesn’t matter for Find, but I will have to review it when I implement Replace, since someone might include non-ASCII characters in the replacement text. I think there will have to be a user control to determine whether to promote ASCII to ANSI or to UTF-8.)
4. Files without a byte order mark that are not pure ASCII and contain any invalid UTF-8 characters are processed using the system default code page. No attempt is made to detect whether a different legacy code page is more likely to be correct, or is explicitly declared within the file.

The sad fact about file encoding is that in most cases there is no algorithmic way to be absolutely certain about what it is. (The exceptions are pure ASCII — but then, if any non-ASCII characters are introduced, there is no way to know how those should be encoded — and some file types, like HTML and XML, that can include a declaration of their own encoding, the declaration itself being in plain ASCII. Byte order marks are, in practice, another exception: they could occur in a legacy encoding, but they would be so uncommon at the start of a file that it’s safe to assume they are definitive, or the file has been purposely engineered to cause mis-detection.)

I will probably improve handling of file encodings as Search++ evolves. I doubt that I will attempt to duplicate exactly what Notepad++ does.

@guy038 said:

So, apparently, the results of the first search seem to speed up all the next same searches, whatever the search engine used ( native one or plugins ones ) !

My guess is that the total size of all the files on your USB key was well less than the amount of memory available to Windows. If so, then (I think) that when you repeated a test, almost nothing was read from the USB key: Windows already had the whole drive cached in memory.

It makes sense that in that circumstance, Search++ would be several times faster, because it uses multiple threads for search in files; I’m pretty sure both native Notepad++ search and MultiReplace are strictly single-threaded. So when the actual searching, rather than reading the files, is what takes most of the time, Search++ is using all cores of your CPU and the others are using just one.

I do wonder, though, why Search++ is so much slower on the first execution. I suspect that something in the way I’m reading files (trying to get several at once, since multiple threads are running) is reducing throughput from the USB key. There is probably a way to make that better. Whether I can figure out what it is remains to be seen.

Thanks for your testing!

Again, thanks for quickly fixing the different issues ( and some others, at the same time ! ). So far, everything looks OK ;-))

Now, I did a test, searching in all files of my D: USB key, with :

• The native N++ Find in Files dialog

• The Search++ Search in Files dialog

• The MultiReplace Find All in Files command

To be sure to process fair tests, I unplung my USB key, re-start my laptop completely, replug my USB key and starts a new N++ session, before running these three Find in Files operations, in turn !

I searched for the Fi string, with the Match case and the Regular expression options checked. I got :

• 27,112 matches in 833 files of 1,761 searched for the N++ Search Results panel, in 1m 37s

• 27,112 matches in 833 files of 1,761 files for the Search++ Search++ Results, in 2m 21s

• 27,087 hits in 835 file(s) for the MultiReplace Search results panel, in 1m 36s

However, when you re-run this same search, without exiting N++, right after the first search, we get the job done in about :

• 6s for the N++ search

• 5.2s for the MultiReplace search

• 1,1s for the Search++ search

So, apparently, the results of the first search seem to speed up all the next same searches, whatever the search engine used ( native one or plugins ones ) !

Best Regards,

guy038

P.S. :

I understood the small differences which occur in the MultiReplace search ( 27,112 - 25 ) matches in ( 833 + 2 ) files. But, I prefer, first, to study more closely the MultiReplace plugin, which is very powerful too and reply later to @thomas-knoefel. It concerns the encoding of 4 files which is not recognized properly and which occurs only when the Find in Files command is used. The Find All and Find in Docs commands, themselves, give correct results for these 4 files !?

• Fix a critical error that caused ICU searches to crash Notepad++.
• Fix unwanted characters appearing at the ends of lines in the Results list with Notepad++ rendering mode GDI.
• Fix regression of line ending symbols being in text color instead of white space color, and switch the CRLF symbol in GDI mode to one that hopefully renders more consistently.

Thanks to @guy038 for catching the ICU error and the unwanted characters in the results list in GDI mode.

(The ICU error appears to have been due to an uninitialized variable. The faulty code has been there from the beginning. As chance would have it, up until now it just happened to land on memory that contained an innocuous value. Hopefully I didn’t miss anything else similar…)

@guy038 said:

But you found out the culprit : it’s just because the GDI ( most compatible) option was selected !. Luckily, for any other option of the rendering mode, after closing an re-starting N++, this special character does not display, anymore !

Thanks for documenting that!

It should appear correctly in GDI mode too, of course. I suspect the problem will turn out to be that GDI mode doesn’t support alpha transparency, so my setting the opacity to zero is doing nothing. I’ll have to find another way.