Text Editor Performance Tests

Discuss anything related to portable freeware here.
Post Reply
Message
Author
TP109
Posts: 486
Joined: Sat Apr 08, 2006 7:12 pm
Location: Illinois/Indiana

Text Editor Performance Tests

#1 Post by TP109 » Thu Apr 16, 2015 8:43 pm

After running into issues with some text editors, I decided to test a few of them to see if they performed differently. Eighteen (18) freeware text editors (17 were portable versions or were made portable) and documented the results. I then contacted Webfork and we corresponded for about 3 weeks or so and agreed that the data would be of interest to this forum and should be posted here. Below is a link to the full report/documentation (includes Word and Excel data files).

Download link for latest documentation:
http://s000.tinyupload.com/?file_id=658 ... 6175294969

Below is a cut-and-pasted portion of my correspondence with Webfork that summarizes my findings.
FYI, the best all around editors in my opinion, at least of the ones I tested, are EditPad Lite7 for general use and Scite or GVIM (Scite is my personal preference) for techies. But for general use, EditPadLite is the clear winner. Really, Editpad Lite blows the other general purpose editors out of the water, at least in performance. It's a well-designed product, as are Scite and GVim. It seems that text editors, like other SW that's either developed by open source teams or by commercial developers, outperform independently developed apps - at least generally. There are of course exceptions, but my findings appear to agree with that general rule. Like I said, some things start to become apparent by looking at these things closely and the well-designed products will come out on top.

So yes, I've changed my mind about freeware text editors since these tests. I would never have picked EditPad Lite before and never thought of Scite or GVim as really being all that good for some reason. The next best are Notepad++, Kudaz, EverEdit, and AkelPad, all of which are good choices for an editor (can't go wrong with any of those). Again, EverEdit went commercial and it's a payware product. The only thing I don't like about the freeware version of EverEdit is that you can't easily associate it with txt files. Most of the others will work fine for small jobs. I was really disappointed by PSPad's performance, although it has a lot of good features and it's still useful.
Last edited by TP109 on Mon Jun 01, 2015 3:57 pm, edited 7 times in total.

User avatar
Userfriendly
Posts: 403
Joined: Tue Nov 27, 2012 11:41 pm

Re: Text Editor Performance Tests

#2 Post by Userfriendly » Thu Apr 16, 2015 11:14 pm

This is interesting. I've sampled freeware/shareware text editors for performance too and settled on notepad2-mod for general use, notepad++ for some extra features and EditPadLite for large txt files. My method of testing was to see which editor handled extremely large files better.

I've tested 64 bit versions of notepad2-mod and sc1(single exe version of scite) they both seem to max out opening a 1.59GB txt file while using 3.3GB of RAM. SC1 is faster and more stable opening the file. Notepad2-mod likes to balloon up to 5GB ram when opening the file, gui freezes a bit, and then drops back down to 3.3GB ram usage. Both crash though when opening files larger than 1.60GB. They both seem to use the same scintilla component but not sure why notepad2-mod is slightly slower.

EditPadLite is much faster opening and browsing extremely large files and caps out at 1.99GB files with 2.3GB RAM use. Though it seems linger on 30% cpu usage for much longer before settling down.

Wish notepad++ had a 64-bit version. I like to use it for quick txt comparisons but its slow when files start to get big. I have to use dedicated compare software for large log files and such.

Other text editors I dropped simply because did not like their GUI or some had too much features or too little.

TP109
Posts: 486
Joined: Sat Apr 08, 2006 7:12 pm
Location: Illinois/Indiana

Re: Text Editor Performance Tests

#3 Post by TP109 » Fri Apr 17, 2015 12:06 am

Userfriendly wrote:notepad2-mod for general use, notepad++ for some extra features and EditPadLite for large txt files. My method of testing was to see which editor handled extremely large files better.

I've tested 64 bit versions of notepad2-mod and sc1(single exe version of scite) they both seem to max out opening a 1.59GB txt file while using 3.3GB of RAM. SC1 is faster and more stable opening the file. Notepad2-mod likes to balloon up to 5GB ram when opening the file, gui freezes a bit, and then drops back down to 3.3GB ram usage. Both crash though when opening files larger than 1.60GB. They both seem to use the same scintilla component but not sure why notepad2-mod is slightly slower.

EditPadLite is much faster opening and browsing extremely large files and caps out at 1.99GB files with 2.3GB RAM use. Though it seems linger on 30% cpu usage for much longer before settling down.
That was going to be my next step, testing maximum file size, but what I did took quite a lot of time. Good to know about the testing that you performed. It provides some data to work with and what to expect. I was going to start at a 250MB file size and continue up at 250MB increments. I'm sure the top performing editors would change positions. Anyway, using a 68MB test file was enough to make some text editors choke. For instance, I did some unofficial testing of Jovial Notepad and Metapad, and both crashed consistently with the 68MB file, but another, Subpad, was pretty good at handling the test file. I didn't test any other notepad type editors because there are so many of them. Also, programming type editors are supposed to be designed to work with large files of code anyway.

I also used notepad2-mod for awhile, but the lack of tabs was a big minus (I'm aware of the add-on directory browser, it helps but no thanks). Personally, I now use Wscite for text editing/coding.

Yes, I also noticed the ballooning of RAM usage for large files. That is why the RAM usage was recorded both with the GUI maximized, then minimized and maximized again. RAM usage will usually go down by itself, but for some editors it's slow. Minimizing the GUI momentarily was a way to determine the minimum RAM usage with a large file more quickly.

No doubt EditPadLite and the Scite/Scintilla (Scite, Wscite, sc1, etc) editors are fast and stable, so your testing agrees with mine. The various Vim flavors (GVim, Cream, Vim, etc.) are fast too, but their interfaces are kind of crappy.

Kudaz was surprising. It's not the fastest loading, but it's stable and loads a small file or large file in about the same time. It's good performance made it a top 5 editor in my testing. Would be interesting to see how it handles really big files.

User avatar
Midas
Posts: 4384
Joined: Mon Dec 07, 2009 7:09 am
Location: Sol3

Re: Text Editor Performance Tests

#4 Post by Midas » Fri Apr 17, 2015 11:10 am

Excellent work! Thanks a lot, TP109. 8)

My only suggestion would be, should you repeat your testing in a foreseeable future, a recommendation to include long time favorites like Win32Pad (http://www.portablefreeware.com/?id=691), Editor2 (http://www.portablefreeware.com/forums/ ... 002#p63002), or even payware UltraEdit (http://www.ultraedit.com/)...

TP109
Posts: 486
Joined: Sat Apr 08, 2006 7:12 pm
Location: Illinois/Indiana

Re: Text Editor Performance Tests

#5 Post by TP109 » Fri Apr 17, 2015 12:04 pm

Midas wrote:Excellent work! Thanks a lot, TP109. 8)

My only suggestion would be, should you repeat your testing in a foreseeable future, a recommendation to include long time favorites like Win32Pad (http://www.portablefreeware.com/?id=691), Editor2 (http://www.portablefreeware.com/forums/ ... 002#p63002), or even payware UltraEdit (http://www.ultraedit.com/)...
Yes, I agree that the most commonly used editors should always be included.

I forgot, but I did briefly test editor2 and it definitely couldn't handle the 68MB test file. It locked up loading the file, after loading it, or just crashed. That is why I didn't include notepad type editors, there were too many that failed during the "weeding out" process. I decided to focus on programming editors instead since they are supposed to be able to handle large files. I guess that testing those editors would be useful even if only to find out which ones can't handle a fairly large file, or to find the best among them. Of the 6 or so of those type editors tested, the only ones that performed decently with the test file were SubPad, ATPad, and SavageEd. I didn't document those failures because the testing concentrated only those editors that could load a fairly large test file, and 68MB isn't really a heavy duty test. All of the programming text editors could load the test file, some more slowly than others of course, where over 50% of the notepad type editors couldn't.

Here are the ones I tested/screened (going on memory and some quick testing now)
Tedpad - failed
ATPad - not bad, loads a bit slowly.
editor2 - failed
SubPad - OK
MetaPad -failed
Jovial NotePad - failed
SavageEd - OK

Keep in mind that I didn't formally test those editors, so take that information for what it is.

TP109
Posts: 486
Joined: Sat Apr 08, 2006 7:12 pm
Location: Illinois/Indiana

Re: Text Editor Performance Tests

#6 Post by TP109 » Fri Apr 17, 2015 6:24 pm

I suppose I should add that CPU usage didn't appear to be a significant factor except for a couple of cases as documented so that value wasn't recorded. However, as UserFriendly pointed out, CPU usage would definitely become a factor for large files and that would need to be monitored/recorded. As I stated to Webfork, these tests are not conclusive, they're a starting point.

TP109
Posts: 486
Joined: Sat Apr 08, 2006 7:12 pm
Location: Illinois/Indiana

Re: Text Editor Performance Tests

#7 Post by TP109 » Sat Apr 18, 2015 4:26 am

I'm testing the same editors now with large text files of 250MB, 500MB, and 750MB or higher if possible. I don't think I will get past 750MB because 1/2 of the editors won't even load a 250MB file without errors or excessive loading times. At 500MB, only 2 editors could load that file within a reasonable time (EditPadLite and Kudaz). I will write all this up and provide the data when tests are completed. I think 750MB will be it, at least on my system. Got curious about this after Userfriendly's post.

User avatar
Userfriendly
Posts: 403
Joined: Tue Nov 27, 2012 11:41 pm

Re: Text Editor Performance Tests

#8 Post by Userfriendly » Sat Apr 18, 2015 6:07 am

TP109 wrote:I'm testing the same editors now with large text files of 250MB, 500MB, and 750MB or higher if possible. I don't think I will get past 750MB because 1/2 of the editors won't even load a 250MB file without errors or excessive loading times. At 500MB, only 2 editors could load that file within a reasonable time (EditPadLite and Kudaz). I will write all this up and provide the data when tests are completed. I think 750MB will be it, at least on my system. Got curious about this after Userfriendly's post.
I have a pretty high end system with 32gb of RAM from 2012 which was $120 total. In hindsight, it was the best decision to go for the overkill at the time. I mean who knew RAM prices would more than double a few months later... Maybe some regret not going 64GB for killer RAMDISK tomfoolery shenanigans insanity.

Anyway back on topic, I would guess you're still testing mostly 32-bit text editors right? Majority of them can't open anything larger than 500MB. Notepad2-mod x64 and custom Scite x64 builds fare better than their x86 counterparts.

I'm also sure you're using EditPadLite x64 version because the installer auto chooses 32/64 depending on the OS. I haven't tried it, but I have no doubt the 32-bit EditPad can handle large files fine too since it somehow uses up much less memory than other editors.

One oddball I tried though is UltraEdit (32bit app) which seems even faster than EditPad because it uses some kind of disk caching/temp file system to work with pretty much unlimited file sizes. Uses about 50MB the whole time while it caches files in the temp folder. Even faster if I use a RAMDisk or SSD for temp files. They got some info on how it works here http://www.ultraedit.com/support/tutori ... dling.html

But I guess these tests don't really mean much for programming since I don't think anybody puts all the code in single massive files. I guess maybe if you open multiple tabs of it. Only reasons I can see is for excessively large databases or log files. At that point it must be for some professional work and maybe UltraEdit and other industrial grade software is worth the price.

freakazoid
Posts: 933
Joined: Wed Jul 18, 2007 5:45 pm

Re: Text Editor Performance Tests

#9 Post by freakazoid » Sat Apr 18, 2015 1:17 pm

Thanks for the research, TP109.

I looked into EditPad Lite based on your findings, but it doesn't look that customizable for my needs. AkelPad fits the bill for me.

I also used SciTE a long time ago. Not sure why I switched, but AkelPad just has too many nifty things for me to switch.

The only time I reach filesizes that large are for log files like Userfriendly mentioned.
is it stealth? ;)

TP109
Posts: 486
Joined: Sat Apr 08, 2006 7:12 pm
Location: Illinois/Indiana

Re: Text Editor Performance Tests

#10 Post by TP109 » Sat Apr 18, 2015 1:56 pm

Thanks for that info Userfriendly. Of course you are correct that database and log files are the only files likely to be that big, that they aren't common, and if they are, users will likely use professional-grade editing SW for them.

I'm testing on an ancient XP SP3 system 32-bit, 2 GB Ram. So yes, my results will be different because of the SW/HW combination I'm using. I have higher end 64-bit systems with Vista and Win 7, but I don't use them as much as the XP system, at least for now. So although my results will differ because of the platform I'm testing with, editor performance is likely to be similar across systems in as far as the editors compare to each other.

I just want to get a rough idea of the limits of these editors. Things certainly change using large files. Although most crash, some will load the 250MB file, but it may take 75 seconds or more to do so and use 1.5GB VM! Anything over 5-7 seconds is excessive in my opinion and you should use something else if it takes that long. Likely to be trouble using an editor like that for big files.

Mostly using manual testing now because the loading is so great it causes all kinds of problems with the automated setup.

I'm not seeing excessive CPU on any of the editors even with large files except for EditPadLite just after it loads. It does settle down, but takes 5-15 seconds for 250MB and up to a minute or so for 500MB. None of the others show any significant CPU usage so far, but VM and RAM really shoots up and they load very slowly, if at all.

Because I learned a bit about editor behavior in my first round of testing, I'm not recording as many parameters for the large file tests. I'm only looking at Launch times, RAM, CPU, and VM for maximized GUI after momentarily minimizing it.

At 500MB, there are only two editors that remain - Kudaz and EditPadLite. All the others become unstable/unusable. I would say that most of the others are not really useful even at 250MB. Even GVim and X-Scite start to change behavior at 250MB, they are no longer fast loading, but will load the 68MB file very quickly.

I'm going to try UltraEdit later.

TP109
Posts: 486
Joined: Sat Apr 08, 2006 7:12 pm
Location: Illinois/Indiana

Re: Text Editor Performance Tests

#11 Post by TP109 » Sat Apr 18, 2015 2:04 pm

freakazoid wrote:Thanks for the research, TP109.

I looked into EditPad Lite based on your findings, but it doesn't look that customizable for my needs. AkelPad fits the bill for me.

I also used SciTE a long time ago. Not sure why I switched, but AkelPad just has too many nifty things for me to switch.

The only time I reach filesizes that large are for log files like Userfriendly mentioned.
I'm only looking at performance. The choice of an editor is a complex decision that takes into account its features, usability, design, and performance. I'm sure you know that, but I'm just stating that here for those who may think I'm testing for the "best" editor.

btw, Akelpad is one of my favorites too.

TP109
Posts: 486
Joined: Sat Apr 08, 2006 7:12 pm
Location: Illinois/Indiana

Re: Text Editor Performance Tests

#12 Post by TP109 » Sun Apr 19, 2015 2:21 am

I completed the large file testing. I will give it the once over before replacing the files in my original post tomorrow. Before I do that, I'd like to clarify what these tests are all about.

These tests are not:
To identify the "best" editor
To determine the most useful editor for programming
To evaluate which editor is easier to use
Or anything else that has to do with usability, usefulness, features, etc.

These tests evaluate only one thing:
How the editors perform in comparison to one another in terms of loading files and resource usage, nothing else. It doesn't matter whether it's the ugliest editor, the barest bones editor, the most feature rich editor or anything else. If anyone is interested in those things, they should do a formal writeup about them. I realize that those types of "popular" articles are what interests most, but that isn't what this is about. This is "hard" data that has nothing to do with "appeal" or other subjective factors. As such, it' not likely to be attractive to the average user.

Hopefully, that clears what these tests are all about.
I appreciate all the feedback, but I also think some are looking at this in the wrong way.

User avatar
tproli
Posts: 1168
Joined: Sat Sep 09, 2006 10:14 am
Location: Hungary
Contact:

Re: Text Editor Performance Tests

#13 Post by tproli » Sun Apr 19, 2015 6:05 am

Did you include EverEdit in the test?

TP109
Posts: 486
Joined: Sat Apr 08, 2006 7:12 pm
Location: Illinois/Indiana

Re: Text Editor Performance Tests

#14 Post by TP109 » Sun Apr 19, 2015 6:40 am

tproli wrote:Did you include EverEdit in the test?
Yes

TP109
Posts: 486
Joined: Sat Apr 08, 2006 7:12 pm
Location: Illinois/Indiana

Re: Text Editor Performance Tests

#15 Post by TP109 » Sun Apr 19, 2015 7:05 am

The new files have been uploaded in the original post.

Post Reply