Text Editor Performance Comparison
This started out as a check on some performance problems which were fixed for the latest version of JOE (version 4.3), but is interesting in its own right as a comparison between some text editors.
Lenovo G570 laptop on AC/mains power
Ubuntu 14.04 LTS 64-bit
Swap = 6 MB
Hitachi HTS545050B9A300 500 GB drive 5400 RPM, 8 MB cache, SATA 3.0 Gb/s
Memory 4 GB (2x 2 GB 1333 MHz DDR3 SODIMMs)
Intel Pentium B970 2.3 GHz Two cores, 64-bit, 2 MB L3 cache
|Notepad++ 6.9.2 (running on Ubuntu in Wine)||Yes||Yes||Yes||Yes|
|Sublime Text Build 3114||Yes||Yes||Yes||Yes|
|Visual Studio Code 1.4.0||Yes||Yes||Yes||Yes|
|ne, the nice editor 2.5||Yes||Yes||Yes||No|
|mcedit (Midnight Commander) 4.8.11||Yes||Yes||Yes||No|
|Gnu Ed 1.9||No||No||No||No|
(*) Windows: yes if the editor allows multiple views of the same buffer on the screen at the same time.
ne uses the syntax highligher code from Joe.
Micro is written in Go.
Jedit is written in Java.
- hello.c Tiny "hello, world!" program
- longlines.txt Two 120KB lines
- test.xml 5.8 MB XML file
- huge 3 GB file (3M 1K lines)
Memory used when loading "hello.c" with syntax highlighting enabled
RSS is amount of physical memory used in KiB. If the editor starts multiple processes, all are included.
Memory used when loading "hello.c" with no syntax highlighting
Memory used for loading test.xml with highlighting enabled
Memory used for loading test.xml with no highlighting
Time used to load test.xml, jump to end of file and exit
Older versions of JOE had trouble with JSON and XML files. The issue was that the context display (the part of the status line which shows the name of the current code function you're in) used a bad algorithm.
Visual Studio Code jumps to the end of the file quickly, but then takes many seconds for the highlighting to complete.
Note that time is total accumulated CPU time of all processes started by the editor. I skip the "exit the editor" part for editors which are indirectly launched (sublime, atom, code, notepad++). For these the CPU time is determined from "ps" or "top -p" after the operation is complete, but while the editor is still running. For editors which are directly launched, I prefix the shell command with "time".
Time used to load test.xml, split window, jump to end of file in other window, insert '<!--' at beginning (so that highlighting of the entire file changes and appears in the window at the end of file) and then exit.
|notepad++||at least 5 minutes|
I could not figure out how to have two views on the same buffer in Micro, NE, mcedit or gedit, so instead I inserted the '<!--' and then jumped to the end of the buffer.
Micro did not recolor the when I inserted '<!--'. It wants to recolor only if the final '-->' exists. In fact Micro did not recolor when I put the '-->' at the end of the file either. Perhaps it gives up recoloring when the file is too large. In any case, I notice that Micro is very slow when you insert characters at the end of the test.xml file.
Jedit did not recolor the other window until after I switched to it and moved the cursor around a little.
Jed is not in this test because it can not highlight XML.
Atom does not seem to highlight large XML files until you "split down" to open a second windows onto the file.
Notepad++ was very slow when I had multiple views open of the same large XML file.
Simple Search and Replace
Time used to load test.xml, and then execute 100,000 replacements (of "thing" with "thang"), and then exit.
|micro||at least 10 minutes|
|nano||at least 10 minutes|
|atom||at least 10 minutes|
In emacs, I used ESC %.
mg has a memory leak in its search and replace code.
Regular Expression Search and Replace
Time used to load test.xml, and then replace the regular expression "100|200" with "EXACT".
In emacs, I used replace-regexp. It's interesting that this is faster than query replace.
Time to load 3 GB file, insert character at start and exit
|nedit||Complains "file is too large to edit"|
|notepad++||Complains "file is too big"|
|ne||Complains "Can't open file (file is too large)."|
|code||Complains "file is very large"|
|jedit||Complains "can not load, negative array size exception"|
|gedit||very slow to load|
|emacs||system hangs: but emacs warns file is "really huge"|
|atom||atom crashes: atom warns "may be unresponsive loading very large files"|
JOE, ED and NVI swap large files to disk, so this test is no problem for them. JOE's RSS is 65756 KiB when the huge file is loaded. NVI's is 2088!
MCedit loads the file quickly into its simple gap buffer. However, the gap is locked to the cursor and distant cursor motions are slow since all of the intervening text has to be copied. Even so, for quick file viewing it's impressive. MCedit's RSS is 3 GB when the file is loaded.
I'm amazed that Sublime Text is also able to load a 3 GB file. When loaded, Sublime's RSS is 1384944 KiB. Sublime is nicer than JOE in that it shows a progress bar while the huge file is loading.
Gedit shows the beginning of the file and a progress bar while the file is loading.
Time to reformat paragraph composed of two 120K long lines
This was slow in older versions of JOE.
I could not quickly figure out how to reformat a paragraph in the other editors.
(*) Micro does not have a paragraph reformat capability, but I notice that it takes 65 seconds to load longlines.txt.