npp becomes slow for large text files, suggest alternative editors

V S Rawat

npp becomes slow for large text files,

I have one file of 1.5 MB, it takes some minute(s) after loading the file to reach from top to bottom just by pressing single command of Control-End.

I have another file of 2.6 MB, it takes many-many minutes after loading the file to reach from top to bottom just by pressing single command of Control-End.

please suggest some free alternative editors that can be used just for doing small changes in such huge files.

The said software need not have npp type of versatile features, I will be using npp for any editing. I will just use that software for copy-pasting text to such huge files and saving the file.

Thanks.

Alan Kilborn

@V-S-Rawat said in npp becomes slow for large text files, suggest alternative editors:

please suggest some free alternative editors that can be used just for doing small changes in such huge files

We’re not really in the game here of suggesting alternatives to our favorite. :-)

But…perhaps try THIS.

artie-finkelstein

You can treat the file contents as plain text by turning off language styling (\Language\None (Normal Text)) or temporarily changing the file extension. The delay is not so much in moving in the file as it is from all the other helpful ‘baggage’ that code formatting supplies.

Alan Kilborn

Artie, I’m surprised you didn’t mention this technique of yours as well: https://community.notepad-plus-plus.org/post/67282

artie-finkelstein

@Alan-Kilborn
It’s actually what I tested with, but I didn’t think adding hardlinking was ‘the most direct way’ to demonstrate how to keep the style lexer from helping.

V S Rawat

@artie-finkelstein said in npp becomes slow for large text files, suggest alternative editors:

@Alan-Kilborn
It’s actually what I tested with, but I didn’t think adding hardlinking was ‘the most direct way’ to demonstrate how to keep the style lexer from helping.

My both huge files are .json, that are used for foxreplace in firefox and its clones.

yes, I have kept language keyword highlights and styling on as a default of npp. If that is causing the delay, I can sure turn that off without loosing any functionality that I require.

Please drop a word to assure.

Thanks.

artie-finkelstein

@V-S-Rawat
I created a hardlink (example for a different file) in my folder of the NppSnippets plugin source code:

mklink /h sqlite3.c.txt sqlite3.c

It’s an 8 MB C file with over 230,000 LoC which I chose simply because it was the largest source code file at hand. By using the hardlink approach, I didn’t change my disk space usage as both names now point to the same storage space on the drive. But, the file sqlite3.c.txt loads in a couple of seconds while the file sqlite3.c. takes an interminable amount of time to load. Any changes made to sqlite3.c.txt will affect sqlite3.c (and vice-versa).

As an additional experiment, after again loading sqlite3.c (and twiddling my thumbs for a while), I turned off file type processing (\Language\None (Normal Text)) and it was quite zippy to move around in the file. But turning lexing back on (\Language\C) again takes an interminable time as over 996,00 tokens (words) must be processed and the editor is once again in molasses mode.

When in the desired speed mode, i.e., while editing sqlite3.c.txt, I searched for the key word ‘return’ and was almost instantly informed there were 9239 matches in the file, and all nicely highlighted in green. The point is, if you can live without the visual sugar of code highlighting, Notepad++ is quite fast on Mongo sized source code files.

As I mentioned in the other post, Notepad++ and ANY other application will consider hardlinked files as two separate files, so it’s up to you to not allow modifications to both at the same time. There are other helpful hints in that post, but I feel this warning is important enough to repeat here.

FWIW: I rarely fire up a console (cmd session) to use mklink now that I’ve installed Link Shell Extension.

PrePS: If hardlinks are not your cup of tea, simply renaming the file also works, but now you must remember to restore the name after editing.

artie-finkelstein

@V-S-Rawat
I forgot to include:
Using Notepad++ on JSON files is not fundamentally different than using it on C files. All that changes is which helpful XML based ‘add-ons’ Notepad++ invokes for syntax highlighting (a/k/a Styling), function lexing for the FunctionList panel and possibly auto-completion (a feature I turnoff in ANY editor I use, so I can’t really comment more on it). By using the file.ext.txt access technique all those features are turned off without changing any of the Preferences… or Style Configurator… settings in the editor as well as leaving the file.ext still accessible to the rest of the development environment, e.g., make, git tools, servers, etc. You still have full search & replace, regex, marking, manual highlighting (now referred to as ‘Style…Token’ in the \Search menu), all the plugins, … Everything but the eye-candy is still available (don’t get me wrong, I use the eye-candy as much as I can as it makes coding & editing much easier).

artie-finkelstein

In case this ~~dead horse~~ deceased parrot is ever viewed again:

I found a third way to speed up the loading of large source code files by manipulating the “langs.xml” file:

Hide or rename the “langs.xml” file. Notepad++ will complain if it can’t locate “langs.xml”, but will continue to work after the warning dialog box is dismissed.
Create an absolute bare-bones version “langs.xml” with all source code sections removed. Full contents of <?xml version="1.0" encoding="UTF-8" ?> works nicely. The file cannot be a zero-length file, it must have some minimal contents.
Just the specific language section can be removed or commented out (surrounded with  tokens):

<!---
    <Language name="json" ext="json" commentLine="" commentStart="" commentEnd="">
        <Keywords name="instre1">false null true</Keywords>
        <Keywords name="instre2">@id @context @type @value @language @container @list @set @reverse @index @base @vocab @graph</Keywords>
    </Language>
-->

As with the file renaming and hardlink creation approaches, there is no syntactic and keyword highlighting or FunctionList available, but otherwise all other features are available.

Neither hiding other folders [userDefineLangs, autoCompletion, functionList] nor hiding other files [functionList.xml, stylers.xml] showed any significant speedup in the file load time. There may be an unique combination of XML file changes that does speed up load time.

NOTE: While variations 1 & 2 will disable formatting for ALL source code files edited, variation 3 only affects the language name commented out.

If large source code files must be edited frequently and both the file rename and hardlink approaches are not practical to use:

Unzip a separate portable version of Npp into Npp4FTB2EE (Npp for files too big to easily edit) <grin>
Replace the default “langs.xml” file with a version based on variation 2 or 3 above
The folders [userDefineLangs, autoCompletion, functionList] and file functionList.xml can be deleted

These variations have been tested and work properly in both Npp v8.1.4rc & v7.9.5 and should also work in earlier versions but YMMV.