Text Editor Performance Tests

Discuss anything related to portable freeware here.
Message
Author
User avatar
tproli
Posts: 1172
Joined: Sat Sep 09, 2006 10:14 am
Location: Hungary
Contact:

Re: Text Editor Performance Tests

#16 Post by tproli »

Thanks. I missed the download link in the first post, now I see.

I wonder if the newer version of EverEdit (3.x branch) would have performed differently (probably not significantly).
But it is already amongst the upper half.

TP109
Posts: 571
Joined: Sat Apr 08, 2006 7:12 pm
Location: Midwestern US

Re: Text Editor Performance Tests

#17 Post by TP109 »

tproli wrote:I wonder if the newer version of EverEdit (3.x branch) would have performed differently (probably not significantly). But it is already amongst the upper half.
I think EverEdit went payware and I only tested freeware editions. Yes, there can be significant differences in versions. For instance, with PlainEdit, there is a big difference between the Net (new) and non-Net (old) versions. I only tested the older non-Net version because the new Net version was slow as heck on my system, so I discarded it. I probably shouldn't have done that, but the number of editors was getting pretty large with all the values, numbers, lists, charts, and such to keep track of and analyze. It becomes a lot of work. It's difficult to include every editor out there, especially if all the poor performers are lumped in too, so decisions are required to narrow the focus. Because of that, someone's favorite won't be included.

And EverEdit has pretty good performance. I rate it in the top third of the ones tested.

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

Re: Text Editor Performance Tests

#18 Post by tproli »

Yes, EverEdit is payware. The 2.9x branch is freeware and it gets only bug fixes as I know.
It becomes a lot of work.
I'm pretty sure about that, thanks for your work and sharing with us!

User avatar
webfork
Posts: 10818
Joined: Wed Apr 11, 2007 8:06 pm
Location: US, Texas
Contact:

Re: Text Editor Performance Tests

#19 Post by webfork »

It became really clear to me how important this topic is today: just try searching for fastest text editor in Google.

Nobody is covering this or even trying to.

Unless the Google results are very incorrect, there's really nothing out there. Additionally, there's only one editor that's trying to be the fastest and the data supporting this boast actually comes from the software's developer so ... it might be suspect. Additionally, EditPad wasn't even included in their tests (unless that's what the "E1" editor was ... it's far from clear).

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

Re: Text Editor Performance Tests

#20 Post by Userfriendly »

Just tried EmEditor. It is indeed extremely fast. Seems to use the same method of temp file caching as UltraEdit. I store temp files in a ramdisk so it blazed through opening a 2gb txt file with random garbage. There's a portable version which is nice too.

But neither EmEditor or UltraEdit are free but they both seem to have a wealth of features and great performance so I guess at least you can say you get what you pay for?

User avatar
webfork
Posts: 10818
Joined: Wed Apr 11, 2007 8:06 pm
Location: US, Texas
Contact:

Re: Text Editor Performance Tests

#21 Post by webfork »

Userfriendly wrote:... neither EmEditor or UltraEdit are free but they both seem to have a wealth of features and great performance so I guess at least you can say you get what you pay for?
Maybe. Although I have heard a lot of good things about UltraEdit, I wouldn't mind seeing that and EmEditor in a future test by TP109. It would be very amusing to see them get beat or at least matched on the speed end by a freeware offering. :)

TP109
Posts: 571
Joined: Sat Apr 08, 2006 7:12 pm
Location: Midwestern US

Re: Text Editor Performance Tests

#22 Post by TP109 »

webfork wrote:Nobody is covering this or even trying to.
I knew before starting that there wouldn't be a lot of interest for this type of information. I have a background in testing and know from experience that testing requirements are often viewed as a burden, a necessary evil, or as wasteful. Eye-candy such as skins, general attractiveness, or "cool" features have the greatest appeal and those are used to market products to the broadest possible audience. Pizzazz and and nifty appearances always generate more interest than performance traits such as speed, stability, compatibility, or reliability.

Loading speed is only one aspect of performance, one that can be measured fairly easily, and it's reasonable to assume that it's related to the other performance traits. An editor that is able to load a large file quickly is also likely to be more stable and reliable. And although speed is a measurement everyone can relate to (by providing bragging rights and such), it isn't everything. Speed comparisons can be insignificant when an editor loads an average sized file 75% faster than the next fastest when the next fastest editor loads it in .6 secs vs .15 secs for the fastest. However, if the speed difference between two editors is 5 secs vs 20 secs for a large file (also a 75% difference), then that is significant.

Although far from comprehensive, the test results reveal quite a bit of information about the development focus and ongoing progress of the editors tested. It should be easier to ascertain which editors are well-engineered from those that are being patched along to achieve acceptance using an appeal to popularity strategy.

Most users are never going to test the limits of an editor in day-to-day usage as was done here, so for them much of the test information/data here may not be of much interest. For a subset of users, such as those working with large files of critical data while on a tight budget, the information could be more useful. However, many probably agree that most users want useful features, usability, AND good performance in a single package, so this information becomes more useful when its combined with other factors such as usability, features, appearance, etc. in selecting an editor. So, by itself, the usefulness of the information is most relevant only to a subset of users, but broadens when combined with other text editor metrics/features.

I will try to test emeditor and ultraedit in the near future if I can (I'm not going pay just to test them). If anyone has any other suggestions, please post them on this thread.

TP109
Posts: 571
Joined: Sat Apr 08, 2006 7:12 pm
Location: Midwestern US

Re: Text Editor Performance Tests

#23 Post by TP109 »

webfork wrote:Additionally, there's only one editor that's trying to be the fastest and the data supporting this boast actually comes from the software's developer so ... it might be suspect. Additionally, EditPad wasn't even included in their tests (unless that's what the "E1" editor was ... it's far from clear).
I took a quick look at that article and it makes a lot of claims that I agree seem suspect. for example:
EmEditor is a smart editor from Emurasoft that can handle pretty much any sized file. 2GB? 20? 200? No problem. A billion lines? Sure. What about really long lines? Is 10 million columns enough, because EmEditor can handle that with ease.
Wow. 200GB? Really? Yet they only tested with 809MB. Hmm. And what is it with those "codes" used to identify the other text editors in their comparison tests? Notepad and Wordpad are the only ones identified, eight others use a "code". What's all the secrecy about? They are making a lot of big claims for sure.

User avatar
SYSTEM
Posts: 2041
Joined: Sat Jul 31, 2010 1:19 am
Location: Helsinki, Finland

Re: Text Editor Performance Tests

#24 Post by SYSTEM »

TP109 wrote:
webfork wrote:Additionally, there's only one editor that's trying to be the fastest and the data supporting this boast actually comes from the software's developer so ... it might be suspect. Additionally, EditPad wasn't even included in their tests (unless that's what the "E1" editor was ... it's far from clear).
I took a quick look at that article and it makes a lot of claims that I agree seem suspect. for example:
EmEditor is a smart editor from Emurasoft that can handle pretty much any sized file. 2GB? 20? 200? No problem. A billion lines? Sure. What about really long lines? Is 10 million columns enough, because EmEditor can handle that with ease.
Wow. 200GB? Really?
Well, it isn't impossible for a text editor to support arbitrarily large files. A text editor "just" needs to not keep the whole file in memory. The user can only see a tiny fraction of the file at a time anyway, so it's unnecessary to keep the whole thing in RAM. If such an approach is used, the size of the file ceases to matter.
TP109 wrote: Hmm. And what is it with those "codes" used to identify the other text editors in their comparison tests? Notepad and Wordpad are the only ones identified, eight others use a "code". What's all the secrecy about?
Yutaka Emura wrote: – For the text editors other than EmEditor and the Microsoft programs, their names have been abbreviated for anonymity.
Depending on the culture and local laws, openly criticizing competing products may be considered rude or even illegal. I guess Emurasoft simply wanted to avoid any potential hassle (and probably they also didn't want to give free advertising to their competitors).
My YouTube channel | Release date of my 13th playlist: August 24, 2020

TP109
Posts: 571
Joined: Sat Apr 08, 2006 7:12 pm
Location: Midwestern US

Re: Text Editor Performance Tests

#25 Post by TP109 »

SYSTEM wrote: Well, it isn't impossible for a text editor to support arbitrarily large files. A text editor "just" needs to not keep the whole file in memory. The user can only see a tiny fraction of the file at a time anyway, so it's unnecessary to keep the whole thing in RAM. If such an approach is used, the size of the file ceases to matter.
Yes, if it's in memory that would make sense. Still like to see that in real life though.
SYSTEM wrote: Depending on the culture and local laws, openly criticizing competing products may be considered rude or even illegal.
Which is why I would be hesitant to test and post any information concerning anything other than freeware/OSS editors. Any claims made about the merits of the commercial editors mentioned would continue to be unsubstantiated by necessity.

User avatar
Nh
Posts: 35
Joined: Tue Jan 22, 2008 5:01 am
Location: Georgia

Re: Text Editor Performance Tests

#26 Post by Nh »

My vote for EmEditor - I use it for 10 years maybe. I tried a lot of other text editors, but every time I would definitely come back to EmEditor. In addition to its great tech capabilities, it is extremely customizable.

User avatar
webfork
Posts: 10818
Joined: Wed Apr 11, 2007 8:06 pm
Location: US, Texas
Contact:

Re: Text Editor Performance Tests

#27 Post by webfork »

TP109 wrote:
webfork wrote:Nobody is covering this or even trying to.
I knew before starting that there wouldn't be a lot of interest for this type of information.
I was actually suggesting there was a gap and that this sort of analysis is very welcome. After all, almost every text editor wants to describe themselves as "fast" but just what does that mean? Fast at what and compared to what?
TP109 wrote:
SYSTEM wrote:openly criticizing competing products may be considered rude or even illegal.
Which is why I would be hesitant to test and post any information concerning anything other than freeware/OSS editors. Any claims made about the merits of the commercial editors mentioned would continue to be unsubstantiated by necessity.
I have a hard time accepting that concern since your tests are pretty straightforward; I'm pretty sure even in those places where it's rude or illegal, you're still free to list car miles per gallon (or kilometers per liter).

TP109
Posts: 571
Joined: Sat Apr 08, 2006 7:12 pm
Location: Midwestern US

Re: Text Editor Performance Tests

#28 Post by TP109 »

webfork wrote:Although I have heard a lot of good things about UltraEdit, I wouldn't mind seeing that and EmEditor in a future test by TP109. It would be very amusing to see them get beat or at least matched on the speed end by a freeware offering. :)
I updated the files in my original post because I found some minor errors. They don't affect any of the results. In summary, Editbone and TotalEdit Pro have a minimized memory value of 3.2 MBs, not 32 MBs with the 68MB test file. I changed that in the report as well. I probably didn't include the decimal point when originally recording the data.

Starting with ver 10, I also updated the Excel analysis spreadsheets to make them easier to use and less error prone by eliminating redundant information and automating the generation of the chart tables. See the link below for the new updated version.

Because of some of the comments made, I decided to go ahead and try UltraEdit (trial version) and emeditor. Emeditor won't launch on my system for some reason so I went ahead with UltraEdit. The trial version launches a trial splash screen with every start that slows down launch time and probably eats up memory as well. I wasn't able to disable the trial version splash screen so that made it impossible to use the automated setup to test launch times. Nevertheless, I tried to work around that by keeping the GUI open and manually opening the 68MB test file to gauge how fast it was. For the empty file launching tests, I disregarded the trial splash screen and considered it launched when the GUI appeared just before the trial splash screen. Although not the ideal situation, it provides an rough estimate of how UltraEdit stacks up to the editors previously tested.

UltraEdit tended to freeze while loading the 68MB test file and even empty launches seemed slow compared to many of the freeware editors. Granted, I'm using the trial version and testing on a XP 32-bit system, so those are probably significant factors. Anyway, I incorporated the UltraEdit data into the previous performance test data so it can be compared with the other editors. I didn't bother testing launch times with the large files, at least for now. The updated Excel file with the UltraEdit performance data is below. Post any questions or comments you may have. I will try testing all these editors using a Win7 64-bit system at a later time.

See original post for the latest files.
Last edited by TP109 on Thu May 28, 2015 1:55 am, edited 1 time in total.

User avatar
lintalist
Posts: 434
Joined: Sat Apr 19, 2014 12:52 am
Contact:

Re: Text Editor Performance Tests

#29 Post by lintalist »

@TP109: the default setup for ultraedit may not be the most ideal configuration to handle large files, UE provides some tips here http://www.ultraedit.com/support/tutori ... dling.html (one thing not listed there is disabling the minimap for example as well which is new in the latest version) - it can certainly handle large files (speaking from experience) but the system and configuration can have a large impact.

In general: text editors are very personal, everyone has different needs and personal preferences. If you are really into text editors you may find http://www.texteditors.org/ to be an interesting site (a wiki with over 1800 text editors listed by OS, type etc)

TP109
Posts: 571
Joined: Sat Apr 08, 2006 7:12 pm
Location: Midwestern US

Re: Text Editor Performance Tests

#30 Post by TP109 »

lintalist wrote:@TP109: the default setup for ultraedit may not be the most ideal configuration to handle large files, UE provides some tips here http://www.ultraedit.com/support/tutori ... dling.html (one thing not listed there is disabling the minimap for example as well which is new in the latest version) - it can certainly handle large files (speaking from experience) but the system and configuration can have a large impact.

In general: text editors are very personal, everyone has different needs and personal preferences. If you are really into text editors you may find http://www.texteditors.org/ to be an interesting site (a wiki with over 1800 text editors listed by OS, type etc)
I made the changes according to the tips and retested. The config changes made no difference for an empty launch, but it did shave off 2-3 secs for loading the 68MB test file, so the launching performance ranking improved by two positions. I updated the results and posted the new files in my original post.

Thanks for the link for texteditors.org. Looks interesting.

I'm going to repeat myself here again because now that a non-free editor has been included, those that use this particular editor may possibly feel a bit "defensive" about the results, especially since they have money invested. The tests are not to determine the best editor, the worst editor, or anything else except to compare performance. Any comments I have made about any particular editor has been based on its performance data. I haven't singled out any editors as being good, bad, or otherwise except based on its performance. I've already stated several times that choosing an editor is a complex decision that involves many other factors. An editor can be useful and desirable even if it has a slower launch and higher memory usage compared to other editors.

See original post for the latest files.

Post Reply