Notepad++ 7.5.9 release

guy038

I’m not the one who deserves thanks ! Indeed, it is Sergey Semushin (alias Predelnick), the creator of DSpellCheck, who found a solution ;-))

Best Regards,

guy038

Fox-E

Just to doublecheck and confirm @guy038 , DSpellCheck’s issue has nothing to do with the big file tabswitch freeze.

With a vanilla Notepad++ install, removing DSpellCheck (and all other plugins, via folder deletion) doesn’t change anything; results are the same as described in prior posts, for both the plain text and javascript test cases.

Seems it’s basically cross-OS too:
Debug:
Notepad++ v7.5.9 (64-bit)
Build time : Oct 14 2018 - 15:19:55
Path : C:\Program Files\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS : Windows 10 (64-bit)
Plugins : none

I have an win xp machine I could try it on, but it looks like @guy038 already did that. I can say though that on win xp, prior Notepad++ versions always had the instant tabswitch with the background rendering.

donho

I can reproduce now by comparing the performance between 7.5.8 and 7.5.9
In my experience, the performance issue has gone after removing DSpellCheck.dll

@Fox-E @Harold-Krueger-IV Could you remove DSpellCheck.dll then see if the issue has gone?

@Predelnik Notepad++ 7.5.8 contains DSpellCheck 1.3.2, whereas Notepad++ 7.5.9 contains DSpellCheck 2.1.4 - so clearly there’s a performance issue in DSpellCheck 2.1.4.

guy038

Hi, Don, and All,

First, Don, after verifying from zip and 7z archives of N++ v7.5.9 ( in versions 32 or 64 ), I suppose that you meant that Notepad++ v7.5.9 contains DSpellCheck v1.4.6.0 ( and not 2.1.4 ?? )
Secondly, I re-tested my 7.5.9 local installation, after removing, either, DSpellCheck.dll file and, even, the DSpellCheck.ini file and the folder Hunspell and I can only conclude that the bug still occurs :-(( At least, on my Win XP laptop !

So, seemingly, it would not be related to DSpellCheck !?

Cheers,

guy038

P.S. :

I had placed all DSpellCheck stuff, in the ..\plugins\Doc folder

Fox-E

@donho No change here, still getting the issue. Checked again just now with a fresh, vanilla 7.5.9 install, deleted DSpellCheck.dll, and tested with Normal Text.

I did just notice though that you specifically have to switch tabs to see the issue; if you open a new tab, and paste a huge file in, it’ll instantly display (basically*) just fine. It’s only when you start switching tabs around that the issue happens.

*: Obviously as you get into really huge files, like 20 MB or 100 MB, it takes more and more time to paste, but this is normal, and has nothing to do with tabswitch freezing.

guy038

Hi @don-ho, @fox-e, and All,

And, above all, ONLY IF the Word Wrap feature is checked !!

Cheers,

guy038

donho

I think I have found the issue and fixed it.
Could you guys test this binary and confirm me that?
https://notepad-plus-plus.org/temp/npp.zip

Fox-E

@donho That fixes it!

For anyone else who wants to test that binary, it’s x86, by the way.

donho

@Predelnik The issue has been identified. Sorry for the wrong presumption.

guy038

@don-ho and All,

It’s OK for me, too, on my Win XP 32 bits laptop !

Thanks for your quick debugging ;-))

Cheers,

guy038

guy038

Hi @don-ho and All,

Regarding the DSpellCheck plugin, and the issue #151, below :

https://github.com/Predelnik/DSpellCheck/issues/151

It’s important to point out that the problem can be observed ONLY IF the option Spell Check Document Automatically option of the plugin is ON !

So, although the DSpellCheck plugin is completely installed, on N++ v7.5.9, you will NOT notice the Exception window, with the message vector <T> too long, when this option is OFF ;-))

But the good news is that the last attempt of @Predelnik, to fix this bug ( see below ) works fine, even on a Win XP config ;-)

https://ci.appveyor.com/api/buildjobs/m8jk80d0t0tm5ixv/artifacts/DSpellCheck.dll

BR

guy038

cmeriaux

@donho said:

I think I have found the issue and fixed it.
Could you guys test this binary and confirm me that?
https://notepad-plus-plus.org/temp/npp.zip

That was my commit ! My bad ! Sorry
I’ll investigate to find a workaroud.

Todd Batzler

It appears that the Folder as Workspace updating problem has returned after being fixed in 7.5.8

Leo G79

@abdelhameedma said:

I got this excetion when trying to use vertical scroller with wider XML file:

Exception

vector<T> too long

fyi, I am using “XML Tools” plugin

I have the same problem. Any fix?

cmeriaux

@guy038 , @donho

About the performance issue you have reported, I’ve found something strange which may be related to the original bug I Tried to fix.
With version v7.5.8 (32-bit) and a big file (520 000 lines, caret on line 200000, like you described in previous post) we don’t have performance issue but when the buffer is activated and available for editing, something is going on beetween notepad++ and scintilla engine. The vertical scroll bar is changing its position. It takes around 15 seconds until background processing stops.

Please checkout my video https://youtu.be/Zfl0HyoukZk

You’ll see the buffer activation of this big file without word wrap and then with word wrap.
You’ll also see process explorer software that show the CPU usage.

Guy, can you please confirm what I saw ?
Thanks

Cheers.

guy038

Hello, @cmeriaux and All,

Christophe, you said

I’ve found something strange which may be related to the original bug

Unfortunately, it’s been a long time since I noticed that using the “Wrap around” option, drastically reduces Notepad++'s global performance :-((

For instance, with the Wrap around option set, time may be significant in order to :

Move to an line, near the end of an huge file, with the Search > Goto... option
Get the very end of an huge file, with the Ctrl + End shortcut
Switch between a “normal” file and an huge one

Note that, with the Don’'s fix, relative to the v7.5.9 version, the delay while switching from a small file to an huge file, has become normal, again, but text may still take up to one second to be displayed, and, unfortunately, this delay increases when the file size is increasing !

As you, I noticed, that after switching to an important file, during 30s about, on my weak XP config, the vertical scroll bar moves slowly downwards, from its exact position and, after the delay, quickly moves back to its correct position ;-))

I did some tests, with the option -noPlugin, on two fresh locale installs of N++, versions v7.5.8 and v7.5.9, with Don’s fix, and with a same important file and results are quite similar and should be identical with prior versions, too !

So, just one rule to remember : if you open an “huge” file, preferably, untick the “Wrap around” feature ;-))

Cheers,

guy038

dinkumoil

@guy038

Is this “huge file” displayed with or without syntax highlighting? Has it a file extension (e.g. .c, .cs , .cpp and so on) which causes it to be parsed by a FunctionList parser? Do you have turned on the Document Map?

cmeriaux

Thanks @guy038
It looks like “wrap around” need a fine tuning ! I’ll put some debug and try ti figure out what’s going on.
The issue might be difficult to understand and might be related to scintilla itself.

@dinkumoil the problem has been highlited with txt files. So function list might not be the culpirt. Document Map was disable. Thanks, that was a good idea.

Christophe

guy038

Hi, @dinkumoil, @cmeriaux, and All,

Indeed, you’ve had a great idea to ask me about some more information ! Because I did some other tests and I found out that what I said, in my previous post, is partially wrong !

My working file, for tests, was created, by accumulation of pages, from this link : https://www.lipsum.com/

At the end, I obtained a .txt file, of 140,770,500 bytes, containing 508,240 lines, that I, then, renamed as Test.cs

First of all, notice that, with this test file, :

switching from any language to Normal text takes 2s about, on my Win Xp config
But switching from Normal text to a specific language needs 22s about, on my *weak laptop !

And this is true, whether or not the Word wrap feature is used.

Now, I always did the same test : starting from line 1 of this huge test file, I noted the time to reach the end of that file, with the simple command Ctrl + End

After numerous attempts, I then realized that, when the Word wrap option is ticked, at least, 3 cases may cause a delay, before seeing the huge file’s text displayed :

After switching from a “normal” file to this big test file
After changing the language of this huge file
After resizing the horizontal length of the Notepad++ window or after moving from a full-screen window to simple window or vice-versa

If I perform one of these three cases, the delay, observed, is between 25s and 32s about, on my Win XP machine !

But, contrary to what I said, in my previous post, it is very important to point out that, ONCE a first Ctrl + End action has occurred, any other action as :

Ctrl + Home or Ctrl + End
Search > Go To..
And, generally, any navigation command, inside this huge file,

are quite immediate ;-)) I’ve never noticed this fact clearly, before :-(( So I apologize for my wrong assumptions !!

And, as soon as you perform, again, one of the 3 actions, described above, the FIRST Ctrl + End action or navigation action takes a significant time ! But the subsequent navigation actions are immediate just as when the Word wrap option is not used :-))

I hope these comments clarify a little bit, things ;-))

Cheers,

guy038

P.S. :

At no time, the Document Map feature was used, during my tests !

cmeriaux

Thanks @guy038 that interesting.

I’ve understood that "line numbering " feature in the margin is very time consuming. Can you try to disable it and check the performance gain ? I have a x2/x3 performance.

There is also a feature to hide some lines of a buffer.
Each time a buffer is activated, for each lines of the files, Npp ask scintilla its status hide/visible ( function [SCI_MARKERGET] https://www.scintilla.org/ScintillaDoc.html#SCI_MARKERGET ). It’s time consuming and we can’t disable it. Maybe adding a option to disable line hidding would be a good idea.

About the GOTO, it’s drastically slow when “line numbering” is actiavated. Without its option, it seems fast enough for me. To be confirmed.
About Ctrl+End / ctrl + Start. Sometime its fast, sometimes its slow. I think it depends on the scintilla buffer cache status.

My conclusion : for huge file, disable line numbering

cheers