I hate Notepad++ because the maximum file size it lets me open is only ...
-
For your information, I don’t hate Notepad++ at all, I just find it an amusing way to ask about the maximum file size Notepad++ (64-bit, version 8.6.8) can work with :-) :-) :-)
-
@scampsd, the maximum file size is something you need to discover for yourself as it varies from machine to machine and person to person. The file size is limited by the plugins and formatting or styling you are using, the amount of RAM in your machine, and your patience.
-
I agree with @mkupper . Many plugins (specifically those implemented in C#) cannot work with files larger than 2^31 - 1 (about 2.1 billion) characters because they use 32-bit integers to index into strings, but I’ve never had the patience to wait however many minutes it takes for NPP to open a 2 GB file anyway.
If you have a really large CSV file (or any other file with reasonably short and consistent-length lines), you might be interested in the HugeFiles plugin, which achieves really good performance in reading (but not editing) files like that by breaking them into chunks and not loading the entire file into memory.
-
@Mark-Olson Thanks, guys, for your quick responses. My question is not related to any plugins: I’m just a basic Notepad++ user (I use it for reading logfiles), so my question becomes: is there any size limitation for Notepad++, without any plugins?
-
@scampsd It also depends on the content of the log files. Very long lines take longer to process than short lines. “Very long” is not an absolute number. Notepad will still work but will be slow if you have thousands millions of characters per line. A month or so ago someone had questions about what they saw when their file was one line long but about 10gb. From what I recall, Notepad++ worked.
I’m still suggesting that you need to try it yourself and see if the results are what you expect or desire. Notepad++ does not have any specific limits other than it will load the file into RAM. The file is usually stored in RAM as UTF-8 encoded data meaning one byte per character for typical ASCII text. If you have 128gb of RAM than I suspect you can work with 100gb files.
@Mark-Olson suggested the huge file plugin. That plugin gets around the RAM limitation meaning you likely can work with files in the exabyte range. The huge file plugin is mainly useful for viewing, not editing, a file.
Do you intend to only “view” 10 gigabyte or longer files or will you desire to do searches on that file? Will those searches use regular expressions? Again, it goes back to you trying it for yourself.
I look at look at my logs files and see one that’s 10,741,311,328 bytes or just over 10gb. Opening it with Notepad++ first causes a pop-up
--------------------------- Opening huge file warning --------------------------- Opening a huge file of 2GB+ could take several minutes. Do you want to open it? --------------------------- Yes No ---------------------------
I click
Yes
and in about 30 seconds (estimated as I did not time this) the file is open. It has 182,531,888 lines. I do a regexp mode search forkjhsdfhkl
which is a random string which should not exist in the file. In 27 seconds the cursor is moved to line 1 with the messageFind: Found the 1st occurrence from the top. The end of the document has been reached.
On the first line the beginning of the line is selected and is12/26/2
I think there’s a bug of some sort here.I then tried an extended mode search for
kjhsdfhkl
. After 68 seconds I get the expectedFind: Can't find the text "kjhsdfhkl" in entire file
A normal mode search took 67 seconds meaning it runs at the same speed as the extended mode search.
Another attempt with the regular expression search took 27 seconds and this time it ended with
Find: Invalid regular expression
plus the complexity thing in the details. The complexity thing comes from the Boost search engine which has a combination of timers and internal event state counts where if they are exceeded that the search is aborted.As extended/normal searches are taking 67 to 68 seconds and the regular expression search fails after 27 to 28 second I decided to try a smaller file that is. 27/68ths of 10,741,311,328 bytes or is 4,264,932,439 bytes long
FWIW - My copy of Notepad++ is using 12,135,796K bytes of RAM. It has a bunch of tabs open but we know most of that is the 10gb log file. I close the tab for the 10gb file and Notepad++'s usage drops to 44,776K bytes. Thus I know the file consumed (12,135,796-44,776) or 12,091,020K bytes of RAM. I suspect that’s the usual one byte per character pus there must be some overhead for the 182,531,888 lines of text.
I did not see a 4,264,932,439 byte file handy but have one that’s 4,438,558,400 bytes and so open that. It takes 10 seconds and Notepad++ is now consuming 5,041,708K bytes of RAM. A regular expression search for
kjhsdfhkl
took 48 seconds and says “not found.” It’s interesting that the Boost engine allowed this to continue. The exact causes of Boost’s complexity error messages have always been somewhat mysterious. Normal and Extended mode searches took 27 and 28 seconds meaning the search rate seems linear with the size of the file. -
FWIW HugeFiles can do regex searches and regex replacements in large files.
The reason I don’t generally recommend this feature is that all find/replace operations are done chunk-by-chunk, meaning that they will fail to find/replace any matches that would cross a chunk boundary. Of course, this is not a problem if your find/replace operations act on a single line and each chunk ends at the end of a line.
-
My logfiles typically are less than one gigabyte, but the more information is needed, the larger they might become, but then I’m talking about sizes about 2-3Gb, I cannot even imagine getting at 5Gb. So this looks to be covered.