5 ms·

Sorry to hear that. We’re improving Atom’s efficiency all the time, but there are definitely areas that we just haven’t gotten to yet.

adtac 9y ago
In your opinion, what, if improved, will give Atom the biggest performance boost?
- maxbrunsfeld 9y ago
  I really want to create a public-facing roadmap that's specific to this issue. Unfortunately, our resources are limited so we often don't focus enough on blogging/publicizing our planning... but in the meantime, here's something of a brain dump: In terms of our actual data structures and algorithms, we're already starting to be in really good shape. We've dropped a number of components of our core TextBuffer to C++, ensured that most of our algorithms scale logarithmically with file size, cursor count, etc, and made use of native threading for important operations. 1. The one remaining structure that we need to drop to C++ is what we call the 'display index' - the thing that stores the locations of things like folds and soft wraps. Once we do that, opening large files (which is already reasonably fast) will be like butter. 2. Our find-and-replace is already pretty good - you can type without almost any lag even when we're storing the locations of millions of search results. But now that we have the ability to easily use background threads, there are some easy optimizations we could do there. The search results could really update instantaneously, we no longer need to wait until you pause when typing in the search box. 3. We have in the works a major change to our syntax highlighting system using my incremental parsing library Tree-sitter. Once this lands, it should eliminate any perceived latency in syntax highlighting (as well as enable a host of great syntax-related improvements). 4. Atom still uses synchronous IO (which blocks the UI thread) in some places. This is because it was created before GitHub created Electron, so node APIs were not available from the outset. Many of these have been eliminated, but there are several Git-related code paths that we still have not updated. This probably kills the experience of editing on remote drives like SSHFS for some users. We need to revisit these code paths.
  - frik 9y ago
    What are the current plans about Coffeescript? I just looked at the code on Github, it says 85% Javascript, 12% Coffeescript. Is the plan to port the 12% to JS6? (and hopefully not Typescript) Great work with Atom editor. I successfully conviced my friends to move from VSC to Atom on macOS.
    - maxbrunsfeld 9y ago
      Thanks! Yeah all of the CoffeeScript in atom/atom should be gone in a few months probably. We use plain JS now. It'll probably take a while before there's no more CoffeeScript in the entire Atom org. We're gradually converting the code to JS as we come upon it for other reasons.
      - frik 9y ago
        Thanks!
    - free_everybody 9y ago
      What's wrong with Typescript? Also, why does it matter to you? Genuinely curious.
      - frik 9y ago
        Curious, Why does it matter to you? On the Atom.io website https://atom.io/ https://atom.io/ it reads "A hackable text editor for the 21st Century". Well I can code in JavaScript 5 and 6. I love love it when a project sticks to web standard, and not have to worry about slangs I don't care about. > Typescript is great at catching bugs The same with JavaScript. Google Closure compiler and anyway most IDEs "understand" JavaScript too and catch bugs. JavaScript is dynamically typed not typeless.
        marcoms 9y ago
        Typescript is great at catching bugs which would trickle down to the end user
pier25 9y ago
I think you are doing a great job. I've been using Atom since 2015 and it's only getting better on each new version. I tried going back to Sublime which has objectively much better performance but that doesn't make the whole experience better. It's like sitting in a Formula 1 car with no cushion and no AC.

adtac 9y ago

In your opinion, what, if improved, will give Atom the biggest performance boost?

maxbrunsfeld 9y ago
I really want to create a public-facing roadmap that's specific to this issue. Unfortunately, our resources are limited so we often don't focus enough on blogging/publicizing our planning... but in the meantime, here's something of a brain dump: In terms of our actual data structures and algorithms, we're already starting to be in really good shape. We've dropped a number of components of our core TextBuffer to C++, ensured that most of our algorithms scale logarithmically with file size, cursor count, etc, and made use of native threading for important operations. 1. The one remaining structure that we need to drop to C++ is what we call the 'display index' - the thing that stores the locations of things like folds and soft wraps. Once we do that, opening large files (which is already reasonably fast) will be like butter. 2. Our find-and-replace is already pretty good - you can type without almost any lag even when we're storing the locations of millions of search results. But now that we have the ability to easily use background threads, there are some easy optimizations we could do there. The search results could really update instantaneously, we no longer need to wait until you pause when typing in the search box. 3. We have in the works a major change to our syntax highlighting system using my incremental parsing library Tree-sitter. Once this lands, it should eliminate any perceived latency in syntax highlighting (as well as enable a host of great syntax-related improvements). 4. Atom still uses synchronous IO (which blocks the UI thread) in some places. This is because it was created before GitHub created Electron, so node APIs were not available from the outset. Many of these have been eliminated, but there are several Git-related code paths that we still have not updated. This probably kills the experience of editing on remote drives like SSHFS for some users. We need to revisit these code paths.
- frik 9y ago
  What are the current plans about Coffeescript? I just looked at the code on Github, it says 85% Javascript, 12% Coffeescript. Is the plan to port the 12% to JS6? (and hopefully not Typescript) Great work with Atom editor. I successfully conviced my friends to move from VSC to Atom on macOS.
  - maxbrunsfeld 9y ago
    Thanks! Yeah all of the CoffeeScript in atom/atom should be gone in a few months probably. We use plain JS now. It'll probably take a while before there's no more CoffeeScript in the entire Atom org. We're gradually converting the code to JS as we come upon it for other reasons.
    - frik 9y ago
      Thanks!
  - free_everybody 9y ago
    What's wrong with Typescript? Also, why does it matter to you? Genuinely curious.
    - frik 9y ago
      Curious, Why does it matter to you? On the Atom.io website https://atom.io/ https://atom.io/ it reads "A hackable text editor for the 21st Century". Well I can code in JavaScript 5 and 6. I love love it when a project sticks to web standard, and not have to worry about slangs I don't care about. > Typescript is great at catching bugs The same with JavaScript. Google Closure compiler and anyway most IDEs "understand" JavaScript too and catch bugs. JavaScript is dynamically typed not typeless.
      - marcoms 9y ago
        Typescript is great at catching bugs which would trickle down to the end user

pier25 9y ago

I think you are doing a great job. I've been using Atom since 2015 and it's only getting better on each new version. I tried going back to Sublime which has objectively much better performance but that doesn't make the whole experience better. It's like sitting in a Formula 1 car with no cushion and no AC.