Hacker News Reader

Comment by forrestthewoods | Hacker News Reader

"and text editors have an insanely high bar to clear in terms of performance and responsiveness"

For some reason that sentence really bothers me. Not because our standards are so high for text editors. But because they're so low for damn near everything else.

View on HN

My first text editor was usable on a machine 300,000 times slower with a million times less RAM. It bothers me that text editor performance is ever considered challenging at all.

http://en.wikipedia.org/wiki/Instructions_per_second#Timelin...

It's probably possible to build a text editor using JS that would be usable in Netscape 4 on a 8 MB machine under Windows 3.1.

What Atom's authors aim is not just being usable; the try to make it comfortable. This a rather higher bar.

For this sort of thing, with a fixed amount of developer time: - Performance - Stability - Actually working

you can pick 2. Also, if you pick performace, 50% of the time you can only pick 1.

Everything is a tradeoff but it's a lot easier to sell something slow than to sell something that doesn't work, and a lot of the performance costs are due to general techniques encoded in these frameworks that reduce bugs.

Another thing is that things do get faster. I think V8 has gotten 10x faster (at least) on real code since its inception. And that's despite JS not having changed.

Sublime Text is all three.

vim has been all three for twenty years.

Vim is not performant. Try scrolling in Vim, then try scrolling in Sublime.

Seems fine on my >500Go aggregated log file. Scroll line by line with no issues. Sed and matching is near instant.

What's the issue ?

I'm not sure why you would open a log file with vim, but that's besides the issue. The issue is with 500 line files. Open one up in Sublime and one in Vim. If you only use Vim you'll never discover what it to means to have a performant editor (I've used Vim for ~10yrs and still regularly do).

I have no idea what you are talking about. I opened a 26,000 line file (no I don't want to talk about it). In vim it opened instantly and my scrolling was only limited by my key repeat rate. The scrolling isn't as smooth looking because vim doesn't animate the scrolling between lines. Sublime took 2 seconds to open the same file, and scrolling was smooth.

Maybe you are using to many vim plugins? I'll admit vim plugins are a real problem, the gui rendering desperately needs to be moved to its own thread.

I think there may be a possibility of the terminal itself being slow. Years ago when I used semi transparent terminals in something like enlightenment it was seriously noticeable when you were trying to scroll through text and it'd take a while to appear. Then I switched to using a simple terminal like rxvt and no transparency effects under ion2 and wow was it fast.

So, perhaps the answer is that it's not the editor nor plugins that's slow in the scenario. I think the line numbering even causes some slight slowdown. Anything that actually parses text will obviously cause a performance hit too. I notice slowdowns when I use visual selection modes combined with tricky combos of commands. Even without any of that, it might be possible that the version of vim is doing something stupid like what happens when you open up a 1GB log file in less and hit G. Haven't run an strafe to understand the fseek calls being made but that's been painful without exception in my experience. Perhaps that's what the poster was recalling.

Vim itself is fine, but the plethora of plugins that a lot of people install can drag it down. Firefox has the same problem with extensions. And it's really not the fault of the base package. It's the plugin developers not doing due diligence, and it's the shear number of plugins making it impossible to test all combinations.

Vim can be blazingly fast and maddeningly slow — it all depends on the plugins you have activated.

i tried but sublime doesn't work in SSH :(

You're right. Editing a large file with syntax coloring and vim slows to a crawl. I just can't get away from Vim though as it works so well in terminals.

This is mostly to do with the syntax matching, the regexes used for that, and thus ultimately also the implementation of the regex engine (which was more or less swapped in Vim 7.4). It bother me a bit too (but not too much). Perhaps it can be mended, we'll see :).

I love ST; I happily bought a v2 license a while ago, and will buy v3 when it's an option. I just get nervous about the resources being allocated to its development, so I've run Atom almost exclusively for a few months as a hedge.

It's worth noting that if you haven't checked in recently, ST3 development appears to be back on track and proceeding at a pretty good clip. (Having said that, I'm keeping my eye on Atom myself. My big concern with ST3 is that the combination of closed source and single developer gives it a bus factor of 1. I'm hoping Jon follows through on his vague plan to get another developer in this year.)

Yeah, that's what I mean by resource allocation. I've downloaded the latest builds, but in my gut it doesn't feel like it's enough.

Cloud9 manages to pull off all 3, and in javascript to boot. I honestly don't notice any difference in performance between it and ST3 (other than initial loading, which is a given seeing as it's web based).

That is definitely not one those "pick two" situations. The relationship between those 3 things is quite different, in fact having one normally implies a better than average chance of having the others.

You can not release a feature until it is performant, stable and working. You just won't release a lot of features. If you have the testing and release procedures that keep things stable and working - testing for performance regressions is easier, not harder.

The classic "pick 2" situations is time, cost, features. Picking any one of those makes the other two harder to do, not easier.

It might have something to do with the demographics. Text editor users are developers, power users, or at the very least, very tech savvy (there is also the other extreme of the spectrum, people who know nothing better, but you get my point). With that demographics, we (at least I know I do) tend to be more picky.

The majority of people are content with coffee-making-loading-time for their OS, and the slug that is called Microsoft Word or Adobe Reader.

MS Word is pretty responsive as an editor. Adobe Reader isn't even an editor.

I'm not a fan, but Microsoft Word 2013 is massively more performant than Atom, at any basic task that both programs do (launching, opening files, find/replace, etc).

Reply on news.ycombinator.com