4 ms·

> I think the point is not necessarily that "text editors intrinsically require gigabytes of RAM and gigahertz CPUs", but that they have "insane" latency requir

> I think the point is not necessarily that "text editors intrinsically require gigabytes of RAM and gigahertz CPUs", but that they have "insane" latency requirements. What about the latency requirements is insane, then? I can't think of what "insane" could possibly mean in this context other than technically challenging or infeasible. > A browser is a tough place to build a text editor. I agree. To some extent I'd call that in itself an "insane requirement". The merge request proves, however, that you can attain reasonable performance by avoiding additional abstractions on top of the already very abstracted platform. Looking at the call graphs, Javascript itself or even the DOM obviously were far from being the bottlenecks.

jerf 12y ago
"I can't think of what "insane" could possibly mean in this context other than technically challenging or infeasible." Apparently, responding to keystrokes by putting a character on the screen in less than a couple hundred milliseconds is still technically challenging, or at least, doing everything we want to do within that time frame is still technically challenging for a high-powered editor. Which is less silly if you think about it. A single keystroke in "notepad" is one thing, a single keystroke in a programmer editor is quite another. "Looking at the call graphs, Javascript itself or even the DOM obviously were far from being the bottlenecks." If Javascript really was a fast language on par with C++ or something, that amount of abstraction would not have been a problem. The fact that Javascript is slow really is a problem. It is not necessarily the problem, because many other things are contributing, but it is a very significant part of the problem. You can bring a Java or C++ program with its knees with too much abstraction too, but it takes a lot, lot more work than that. (Many have managed to leap this bar and more, though!) It's one of the reasons I'm really trying to get the 1990s-style dynamic scripting languages out of my professional life. It really isn't that hard to reach a point where you simply can not have both of "a good design" and "sufficient response time" because you literally want to do more work than the language can get done on one core in 100ms unless you essentially manually inline everything, but that's not practical for its own reasons. In fact, on that note, note that this is it for Atom. This is the fastest they can go with this layer. Should they end up pushing the editor a bit farther and should they end up needing a bit more performance to do something else properly, they won't be able too, because they just tapped out this well.
- tracker1 12y ago
  Does it really need to happen on one core? The platform supports webworkers and serializing certain events across channels wouldn't take much... if you look at, for example some of the cross channel rendering with react that has been experimented with, there's merit there.
  - jerf 12y ago
    For this use case, I suspect you wouldn't be able to win much with WebWorkers. You'd have to profile, but having done a lot of profiling with multithreading in several environments I've learned to expect disappointment relative to my initial lofty hopes. It feels like it ought to be easy to get linear speedups and that it ought to take something really unusual and special to slow it down; in practice you're lucky to even get "good" speedups.

jerf 12y ago

"I can't think of what "insane" could possibly mean in this context other than technically challenging or infeasible." Apparently, responding to keystrokes by putting a character on the screen in less than a couple hundred milliseconds is still technically challenging, or at least, doing everything we want to do within that time frame is still technically challenging for a high-powered editor. Which is less silly if you think about it. A single keystroke in "notepad" is one thing, a single keystroke in a programmer editor is quite another. "Looking at the call graphs, Javascript itself or even the DOM obviously were far from being the bottlenecks." If Javascript really was a fast language on par with C++ or something, that amount of abstraction would not have been a problem. The fact that Javascript is slow really is a problem. It is not necessarily the problem, because many other things are contributing, but it is a very significant part of the problem. You can bring a Java or C++ program with its knees with too much abstraction too, but it takes a lot, lot more work than that. (Many have managed to leap this bar and more, though!) It's one of the reasons I'm really trying to get the 1990s-style dynamic scripting languages out of my professional life. It really isn't that hard to reach a point where you simply can not have both of "a good design" and "sufficient response time" because you literally want to do more work than the language can get done on one core in 100ms unless you essentially manually inline everything, but that's not practical for its own reasons. In fact, on that note, note that this is it for Atom. This is the fastest they can go with this layer. Should they end up pushing the editor a bit farther and should they end up needing a bit more performance to do something else properly, they won't be able too, because they just tapped out this well.

tracker1 12y ago
Does it really need to happen on one core? The platform supports webworkers and serializing certain events across channels wouldn't take much... if you look at, for example some of the cross channel rendering with react that has been experimented with, there's merit there.
- jerf 12y ago
  For this use case, I suspect you wouldn't be able to win much with WebWorkers. You'd have to profile, but having done a lot of profiling with multithreading in several environments I've learned to expect disappointment relative to my initial lofty hopes. It feels like it ought to be easy to get linear speedups and that it ought to take something really unusual and special to slow it down; in practice you're lucky to even get "good" speedups.