Edit: We need a type system which makes O(n^2) algorithms illegal. (Yes... I know what I just dialed up. You can't see it, but I'm giving a very big ol' evil grin.)

For example, the find and replace package uses markers to highlight search results, and if you ran a search for the letter e in a large file, the excessive time spent updating thousands of markers on every keystroke was intolerable

This suggests another problem they have is a huge constant, in addition to the algorithmic one --- "thousands" shouldn't be something a modern machine would choke on, if updating positions is a simple operation like increasing their offset by 1 after a character is inserted. On a CPU that can do one billion instructions per second (a good OOM estimate, which still underestimates how fast real CPUs today are by a few times), adding 1 to 10000 variables should not take any perceptible amount of time --- less than a millisecond.

Going from 800ms to 50ms is a great improvement, but I think that's still several orders of magnitude slower than what the machine can really do.

As I mentioned in the article, a big part of the cost was updating a different interval storage structure as the markers were updated since the absolute positions approach left us no way to defer it.

"Extension" should probably be in scare quotes because the implementation is literally just CSS animation: https://github.com/dmnd/rainbow-selection/blob/master/styles...

There's no good reason such an animation should be taxing your machine. It works fine on my MacBook Pro. But someone else reported this issue too: https://github.com/dmnd/rainbow-selection/issues/3

If you're interested in working out what's going on, please respond to that github issue. I understand if you don't want to spend time on such a trivial thing. But you spent the time to write this comment, so I figured maybe you're interested :)

> Column numbers in Firefox. Firefox is the only browser that doesn't support column numbers for exceptions. This makes debugging minified javascript essentially impossible. I've sent one patch but there's a lot more to do.

https://bugsnag.com/blog/js-stacktraces/

- written in 2014

but MDN now says:

> Column number for the line where the error occurred (number) - Requires Gecko 31.0

https://developer.mozilla.org/en-US/docs/Web/API/GlobalEvent...

If anybody has live experience with this, I'm eager to hear about it.

It's always a little weird, because I have no performance issues anywhere else in it, and it's got ~7GB of RAM it could use.

I don't know what happened after that. Maybe they will act on this. The only problem with the O(n) engine was that a lot of TextMate grammars for languages wouldn't work with atom but that was easily resolvable by writing them anew.

https://youtu.be/4i7KrG1Afbk?t=1251

[0] https://github.com/martanne/vis#text-management-using-a-piec...

[1] https://github.com/martanne/vis/blob/master/text.c#L1152

But I had so many issues with stability, and really missed small but important features that were present in my other editors. I also found that most of the plugins worked either poorly or sporadically.

In the end, I decided that it was not worth either using Atom or spending time contributing to it when I have some "pretty close" solutions today. Definitely looking forward to the 1.0 version though, and hats off to all those spending their time contributing to it. I'm sure it's going to become something great!

Neither it nor Notepad++ could handle gigantic text files, which is a real shame as well, though not a point of comparison.

Having said that I'm fully stoked with it in other respects; and I can see the minor annoyances getting fixed.

Atom will be a really nice editor, it's just going to take some time, and it does have rough patches now and then.

That said, I'm loving the API design. Coming from Sublime Text, it's a massive upgrade. The ability to embed literally anything a web browser can render in a well-designed framework is mindblowing.

Thanks for bringing this up. It's not a fundamental limitation at all. Highlights whose markers are zero-width are deliberately filtered out here[1]. This might not be the right move. If you've found it inconvenient, would you mind opening an issue on atom/atom, and describing your use case?

[1] https://github.com/atom/atom/blob/ebc5758d79e421f61f2b6669a8...

Thanks in turn. :)

https://en.wikipedia.org/wiki/Enfilade_%28Xanadu%29

Solve it, keep it secret, and then fail to properly write about it to this day.

Of course, one could just write a native interface for every OS, but then that adds a new layer of complexity. HTML & Javascript engines are nowadays well optimised and available everywhere, making them the only real choice as a replacement for terminals.

I'm really happy with Atom's development, it has come very far in a relatively short time.

One of the main remaining functionality to be implemented is good support for large files. Looking at this issue [1], it seems Atom team is making some progress but there are still some problems to be tackled.

In 0.208.0 (released 7 days ago) they mentioned in the changelog Atom now opens files larger than 2MB with syntax highlighting, soft wrap, and folds disabled. We'll work on raising the limits with these features enabled moving forward. Little bit disappointed at the progress as you could open large file with these features disabled long time ago through a package "view-tail-large-files".

Just updated to 0.209.0 and using ember.js (1.9 MB) to test. Editing/scrolling has some delays but it's better than previous versions.

Good luck Atom team!

[1]: https://github.com/atom/atom/issues/307#event-325455529

Electron is not an editor itself. The Atom editor is built as an Electron app, and so is Visual Studio Code, but Electron is not an editor. It's not even an editor framework. When you hear "Electron", think "Cordova for the desktop". Sort of.

That seems to be the extent of the similarity between the two--that they're each packaged as essentially a single page app for a Chromium-based, site-specific browser runtime.

For more info on VSC, see castell's comment from last week[1] and this post[2] from Scott Hanselman a couple years back (including the comments).

1. https://news.ycombinator.com/item?id=9691289

2. http://www.hanselman.com/blog/ARichNewJavaScriptCodeEditorSp...

  | Root              |
  | Node        | Node|
  | Node | Node |

It was a bit more human-readable when looking at the data. More importantly, it reduced (on average) the number of nodes I needed to update on insert compared to nested set and gave an easy way of retrieving immediate children. But you still had to "move over" all the nodes "right" of the one you're inserting.

The structure in the article looks eerily similar. I wonder whether it's somehow possible to apply GitHub's optimization to this "coordinate" based schema and make it relative without messing up the benefits of column indexing. Hm...

It is an OLD i3 Dell from 6 years ago desktop.

I've been running it for ages on a mbp with 2.6GHz i5/8Gb RAM. It's lightning fast.

Very occasionally it will appear to be hogging CPU - typing is slow and it might hang for a couple of seconds when you're navigating around. This only seems to happen when I've had it running for days if not weeks without a restart. I just restart it and it's back to being lightning fast.

I really like Atom and would be pretty upset if it stopped working well for me, so would be curious to know what kinds of things people suspect cause it to have issues.

Is it just that my machine is powerful enough to not notice, and it's only really a problem on less powerful machines? I don't run many plugins, and installing many of these tend to bring it down? It runs well on OSX but not other platforms?

It's important for Atom's extensibility that these kinds of events are provided, because it allows many major editor features to be implemented as separate packages, but it means that naively-implemented packages can really slow things down.

Many Atom packages are pretty new, and their authors may not have put a lot of effort into optimization yet. In the past few months, the team has put a lot of effort into stabilizing and solidifying our APIs. We're hoping that now that the APIs are stable, the package ecosystem will really start to mature.

I suspect that people who complain about speed are either on lower end hardware or are comparing it directly to a native editor directly and consider any typing latency at all to be unacceptable.

Do you literally mean that it hangs for a couple of seconds? That seems like an eternity, especially if it happens during navigation.

[1] I know such a search is ridiculous, but both editors perform search-as-you-type, although atom does attempt to delay that if you type quickly enough. Anyway, it's just an example to demonstrate the speed difference.

The built in search is slow (for now), but they have been steadily making gains and use performance testing to measure progress.

Good news, it exists. If you know Go it's possible to see it sooner: http://limetext.org/