Lags during up and down navigation with arrows on large PHP-file, 500 Kb, 16k lines



  • Hello!

    Just hold up or down arrow button on the keyboard and during such navigation code area hangs some times for 0.5 second or less.

    There are more lags when I try to do same but with selection, hold shift and hold up or down arrow button.

    Much more lags with function list panel.

    I have tied to:

    • hide bookmarsk left panel
    • hide block border left panel
    • hide function list panel
    • disalbe word wrap
    • disable showing special chars
    • disable intent vertical lines

    but lags are still there.

    Notepad++ v7.9.2, Windows 10 64-bit
    I have used version 6.6.8 (2014 year) for years and there was no such lags.

    Is it possible to fix it?



  • @Egor-Artemenko ,

    Interesting: when I had a file that looks like

    <!DOCTYPE html> <html> <body>
    <h1>My first PHP page</h1>  <?php echo "Hello World!"; ?>
    <h1>My first PHP page</h1>  <?php echo "Hello World!"; ?>
    ...
    <h1>My first PHP page</h1>  <?php echo "Hello World!"; ?>
    </body> </html>
    

    I do not get any lag.

    However, if I have a file that is 16k copies of

    <!DOCTYPE html> <html> <body> <h1>My first PHP page</h1>  <?php echo "Hello World!"; ?> </body> </html>
    

    then I do occasionally get a lag. If I go up to 1M copies of that line, I frequently get a lag, but that’s a 100Mb file, so not unexpected.

    If it’s consistent for you, even at only 16k lines, you might want to look into your plugins, and see if any of them are causing a lag. Easiest way to check is to run with the -noPlugin command line option, and see if that clears up the lag. If that doesn’t fix it, that’s not the problem; if it does fix it, then you will need to manually enable/disable your plugins (temporarily rename the plugins/ dir subfolder for that plugin and restart notepad++) to figure out which plugin is causing the problem. If no plugins are loaded and it’s still laggy, try renaming the file to .txt before loading it in Notepad++; that way, it will load as plain text instead of with the PHP syntax highlighter, and you can see if it’s the syntax highlighter that’s causing the problem. If it is the syntax highlighter, then my guess is that you have some tags that are opened but not closed, so when the highlighter tries to find the matching tag, it gets confused for half a second. If it really is just matching-tags, you might be able to fix it by disabling Settings > Preferences > Highlighting: Highlight Matching Tags entries

    To help us help you in the future, sharing the Debug Info (from ? menu) is helpful:

    Notepad++ v7.9.2   (64-bit)
    Build time : Dec 31 2020 - 04:01:34
    Path : C:\usr\local\apps\notepad++\notepad++.exe
    Admin mode : OFF
    Local Conf mode : ON
    OS Name : Windows 10 Enterprise (64-bit) 
    OS Version : 1903
    OS Build : 18362.1256
    Current ANSI codepage : 1252
    Plugins : ComparePlugin.dll ExtSettings.dll HexEditor.dll LuaScript.dll MarkdownViewerPlusPlus.dll mimeTools.dll NppConsole.dll NppConverter.dll NppEditorConfig.dll NppExec.dll NppExport.dll NppFTP.dll NppUISpy.dll PreviewHTML.dll PythonScript.dll QuickText.dll TagLEET.dll XMLTools.dll 
    


  • Hello, @egor-artemenko, @peterjones and All,

    When the arrow keys do not act, immediately, your may try the DOS command, below, which resets the keyboard parameters to :

    • The maximum rate of repetition ( 31 ), once a key is pressed

    • The delay, before repetition, to the 0 value

    mode con rate=31 delay=0

    Verify the result with the command mode con. And the mode con /? command explains the different parameters !

    Of course, this command acts, globally, on the OS and not just on Notepad++

    Best Regards,

    guy038



  • @PeterJones,

    My php consist of only functions with PHP-code and no HTML-tags, like this:

    <?php
    
    function func() {
    }
    

    like this file (I’ve found some example on github):
    https://github.com/deluxscript/e5-wp/blob/739d67070edcc9ca8f10c690fef53c2ccf312965/wp-includes/deprecated.php
    You can copy content of this file 5 times (copy without “<?php”).

    I’ve notices that no lags in the beginning of the file and much more lags in the end of file.

    -noPlugin does not affect, save lags without any plugins.
    Disabing Settings > Preferences > Highlighting: Highlight Matching Tags helps, no lags at all after disabling.

    But no lags with same settings was in the old 6.6.8 version with this setting enabled, that I’ve used before.

    Debug info:

    Notepad++ v7.9.2   (64-bit)
    Build time : Dec 31 2020 - 04:01:34
    Path : C:\XPrograms.Portable\Notepad++\notepad++.exe
    Admin mode : ON
    Local Conf mode : ON
    OS Name : Windows 10 Pro (64-bit) 
    OS Version : 2004
    OS Build : 19041.746
    Current ANSI codepage : 1251
    Plugins : ComparePlugin.dll DSpellCheck.dll JsMapParser.NppPlugin.dll JSMinNPP.dll LanguageHelp.dll mimeTools.dll NavigateTo.dll NppConverter.dll nppcrypt.dll NppExport.dll NPPJSONViewer.dll NppMarkdownPanel.dll NppTextViz.dll NppXmlTreeviewPlugin.dll RegexTrainer.dll urlPlugin.dll XMLTools.dll zoomdisabler_x64.dll _CustomizeToolbar.dll 
    


  • Hi, @egor-artemenko, @peterjones and All,

    After duplicating ten times the PHP file, provided by @egor-artemenko, I can confirm that, with the v7.8.5 N++ release :

    • When caret is in the first part of file, the caret can be moved easily, without any delay

    • When caret is in the last part of file, delay, after hits on arrow keys, are quite significant

    • When disabling Settings > Preferences > Highlighting: Highlight Matching Tags, no more lag

    • Of course, using the Normal Text language does not produce any lag, too !

    BTW, all this occurred with a correctly set-up keyboard !

    BR

    guy038



  • Scanning lots of text takes time.
    Scanning for opening/closing brace across entire document will take a bit of time. Even without a lexer (normal text).
    Scanning entire document to perform syntax highlighting takes LOTs of time. Depending on the efficiency of the syntax highlighter.

    Note that scanning for closing brace (forward) will also trigger syntax highlighting since brace logic needs to know the type of text to match the brace.

    For healthy C code, opening/closing brace will never be more than ~200 lines away so scanning will not traverse more than a few kilobytes and will feel instantaneous. A C file of over 100Kb is considered very big. If PHP (which I don’t know) have an opening brace at its beginning that is only matched at its end then every jump to start/end of a large document will be costly.

    A common design for syntax highlighting lexers is to maintain a valid lexing from start of document until end of current view area. Modifying text will invalidate lexing info from modification place to end of document. Jumping to end of document will trigger lexing of entire document even though user never looks at most of it. This makes perfect sense considering many languages can have an “open comment” at the beginning of the document that changes entire text into a comment.

    Optimizing for 500Kb files or 500Mb files is not a high priority for developers of Notepad++, Scintilla and plugins.

    The main reason for slowness is probably the PHP (HTML) lexer which is maintained by Scintilla. Perhaps it was improved since version 6.6.8 to do better lexing at slower speed. Feel free to use Scintilla forums to complain.

    Brace highlighting can be tweaked. E.g. have a “give up” scan distance. But since most users don’t experience this problem … I wish you good luck in convincing developers to add that tweak.



  • @gstavi

    Another tweak is detecting fast actions, for example holding down arrow, and temporary disable heavy features like highlighting braces.

    Is this tweak for Notepad++ or Scintilla?



  • @Egor-Artemenko said in Lags during up and down navigation with arrows on large PHP-file, 500 Kb, 16k lines:

    Another tweak is detecting fast actions

    Extremely unlikely.
    The core design of Notepad++ and Scintilla is single threaded.
    Once an “event” should do some computation this computation is happening and even if it is unexpectedly long there is no way to abort it.
    With “fast actions” which is practically 2 quick events the 2nd event cannot influence the 1st event.


Log in to reply