8 ms·

Does anyone know on a technical level why the Monaco editor feels so much faster than the Atom editor? Is there any mechanism Microsoft is employing that Atom c

by tiles 10y ago

Does anyone know on a technical level why the Monaco editor feels so much faster than the Atom editor? Is there any mechanism Microsoft is employing that Atom could adopt, or are the two editors that fundamentally different?

Secretmapper 10y ago
Does Atom still feel slower? I've used Atom before and it did feel sluggish, and using VSCode for TypeScript really felt lightyears ahead from Atom. (maybe a bit unfair of a comparison since it's most likely nicely integrated for it, but whatever) To be fair I haven't caught up with their current versions (I'm a vimmer, I just tried them) but I think I tried Atom after the React move.
- rattray 10y ago
  Atom has gotten incrementally faster and I have few problems using it as my main editor at work, on a Macbook Pro with 16GB of RAM. It isn't pleasant to use on my personal laptop (MBA with 4GB RAM) where I frequently switch projects. While I am a happy Atom user, I am disappointed with performance; I think there's an order-of-magnitude jump in overall speed that the editor could really use.
  - Loic 10y ago
    You are talking about 16 GB of RAM, rights? My emacs is very happy with 32 MB of RAM and my vim with even less. I understand that Atom is doing a lot, but if you need 16 GB of RAM to run your text editor, this simply means that the developers have not been using the right data structures to manage the state of the application or maybe the new code editors have an implementation of an AI coding for you so you can outsource yourself.
    - Longhanks 10y ago
      That's the price you pay for Electron.
      - rattray 10y ago
        The reason we're talking about Atom on this thread is because VSCode, which also uses electron, does not have performance issues.
        vortico 10y ago
        Which makes me think, Atom is giving Electron a really bad reputation for its speed. Sure, it consumes tons of RAM, but it's not that slow by default.
    - rattray 10y ago
      Many people use full IDE's to do their work - JetBrains, VS, etc - which are dramatically more resource intensive than Atom.
      - siddhant 10y ago
        Yes but they are IDEs, while Atom/Vim/Emacs are plain text editors.
        teacup50 10y ago
        ... and Emacs really is an IDE; the distinction between it and GUI IDEs has more to do with user interface than any limitation of Emacs. e.g. live libclang-based code completion for Emacs: https://github.com/Sarcasm/irony-mode https://github.com/Sarcasm/irony-mode
        adrusi 10y ago
        Atom is essentially the same class of editor as emacs. Both have designs that can accomodate IDE features (so does vim, but it's more of an afterthought in that case), but normal usage is not IDE-like. Atom is essentially emacs built atop javascript+web rather than lisp+unix.
        fallenshell 10y ago
        This is more holy war material than anything really. Emacs is just an editor.
        daigoba66 10y ago
        > plain text editors I don't think that's a fair assessment given the what is now minimum expectations around syntax highlighting, syntax/grammar validation, autocomplete, etc. We're no longer dealing with "plain text".
        cyphar 10y ago
        So that's even less of an excuse for Atom's resource hogging. Vim and neovim use so little memory and are probably the most responsive editors I've ever used.
    - rkangel 10y ago
      I was going to say that my emacs uses an awful lot more memory than that, but actually it's got 190 files open in at least 3 languages and it's using 89.8 Mb of RAM at the moment. Atom is at a fundamental disadvantage - it's built on a much more complicated and abstracted stack of technologies. Javascript engines do spectacular things these days but they have a harder job to do than executing compiled lisp, and that's before you look at the whole of the rest of the stack involved.
    - toomanybeersies 10y ago
      And to think people used to say emacs stood for Eight Megabytes And Constantly Swapping.
      - ank_the_elder 10y ago
        And let's not forget: Editor for Middle Aged Computer Scientists Escape-Meta-Alt-Control-Shift Tt's still my favourite, though.
    - fallenshell 10y ago
      I've been an avid Sublime user for many years and still am, and this is what puts me off any electron based editor or app in general. The requirements for the most trivial things are so high, it is insane. Try running Atom on a AMD E1 laptop. TLDR, not very nice.
    - bbcbasic 10y ago
      It's new paradigm - bloatier than an IDE, as slow as a web page but without the advantage of storing / running anything i n the cloud.
  - caconym_ 10y ago
    Last time I seriously tried using it, it seemed unnecessarily CPU-hungry and my battery life suffered as a result. That fact alone was enough to get me to stop using it. I have a weird thing about inefficient software in general, but in this case its inefficiency was actually inconveniencing me. With my good old Vim+tmux workflow, my 12" Macbook claims it'll go for 14-15 hours, though I haven't ever fully tested that claim.
  - toomanybeersies 10y ago
    I used Atom for 3 months over New Year's on a 4 GB 2015 MBA. I had no issues whatsoever. Interestingly enough, Atom seems to really struggle on my Windows laptop, it's often incredibly choppy. It actually runs better in a Linux VM than natively on Windows.
    - SOLAR_FIELDS 10y ago
      The only consistent issue that I have had with Atom since I started using it in late 2014 was the handling of large files. It has gotten incrementally better, as others have stated, but trying to open up, for instance, a JSON file larger than 10-20 megabytes in the editor causes the editor to be brought to a grinding halt.
JoeCoder_ 10y ago
From the FAQ. https://github.com/Microsoft/monaco-editor#faq https://github.com/Microsoft/monaco-editor#faq: "Why all these web workers and why should I care?" "A: Language services create web workers to compute heavy stuff outside the UI thread. They cost hardly anything in terms of resource overhead and you shouldn't worry too much about them, as long as you get them to work (see above the cross-domain case)." Maybe that's part of the reason?
- amasad 10y ago
  I think that's pretty much standard practice. I'm not sure about Atom but Ace leverage's workers for linting, intellesense and things like that.
  - c-smile 10y ago
    Educated guess: generator functions with chunked processing on setInterval callbacks would be less CPU consuming for such tasks.
    - EGreg 10y ago
      Pretty sure setInterval still uses the same processor core, wasting the others
alexdima 10y ago
Hi, I'm working on the editor since almost 5 years now. Phew, time flies. There is no silver bullet, we mostly try to keep all computations limited to the viewport size (if you have 20 lines visible, then typing, colorizing, painting a frame, etc. should all end up being computed with loops covering those 20 lines and not the entire buffer size). We also use extensively the profilers, and most recently (last month) I learned about this great tool called IR Hydra[1]. The gains from eliminating bailouts in the hot code paths are probably too small to notice (5-10% per render), but I like to think that everything adds up. We use translate3d for scrolling (except in Firefox which has a known bug[2]) and that brings down the browser painting times considerably when scrolling. I've also found insertAdjacentHTML to be the fastest way to create dom nodes (from big fat strings) across all browsers. Sort of silly to mention, but we use binary search a lot :). [1] http://mrale.ph/irhydra/2/ http://mrale.ph/irhydra/2/ [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1083132 https://bugzilla.mozilla.org/show_bug.cgi?id=1083132
- tiles 10y ago
  Thanks for this. :) Learning the type of tricks needed to get DOM performance are hard-won, I imagine, so hearing it straight from a developer is extremely valuable to me.
- alexdima 10y ago
  Forgot to mention a funny fact I found. Minify everything [1] [1] https://top.fse.guru/nodejs-a-quick-optimization-advice-7353b820c92e#.nfvi89hjc https://top.fse.guru/nodejs-a-quick-optimization-advice-7353...
  - vanderZwan 10y ago
    > v8 optimizer (crankshaft) inlines the functions whose body length, including the comments, is less than 600 characters. In what kind of world is that a sensible metric to decide if a function can be inlined?
    - luckystarr 10y ago
c-smile 10y ago
The editor is essentially a virtual list - sliding buffer of DOM elements - only visible lines are represented in the DOM. That's probably the only reasonable way of doing such editors effectively in modern browsers. Drawback of this approach: hard to integrate platform scrollbar to that, quite a lot of JS code to support virtualization, etc. Speaking about syntax/text highlighting in HTML ... In Sciter I've added an option [1] to mark character runs without creating tons of heavy weight DOM elements (The Monaco uses <span>'s for that). Plus an option to style those run marks in CSS: plaintext > text::mark(keyword) { color: blue; } plaintext > text::mark(symbol) { color: brown; } Editor's DOM model in Sciter's case is a flat list of <text> elements representing each line. <plaintext> <text>first line</text> <text>first line</text> ... </plaintext> In fact such marks are needed not only for syntax colorizing but for other things like misspelling highlighting, text found highlighting and other cases where you need to highlight text but DOM change is highly non-desirable. [1] Tokenizer + ::mark() = syntax colorizer : http://sciter.com/tokenizer-mark-syntax-colorizer/ http://sciter.com/tokenizer-mark-syntax-colorizer/
- xuejie 10y ago
  Not an expert here so I might be wrong, but I've been reading about Framework7(http://framework7.io/ http://framework7.io/) lately, which uses both virtual list and native scrolling. So maybe you might not have to implement custom scrolling here? It could also be that mobile CSS has its own quirks so different implementation can be used, again, not a DOM expert here.
  - c-smile 10y ago
    Check this: http://sergimansilla.com/blog/virtual-scrolling http://sergimansilla.com/blog/virtual-scrolling it is an example of virtual list showing 1,000,000 records with native browser's scrollbars. So "yes" it is doable in principle but with JS help of course. And yet only for items of the same height.
FuturePromise 10y ago
I sort of like Atom but it's way too slow, buggy, and quirky for me to love it. I'm looking forward to trying Monaco. You'd think it would have the same problems being javascript-based, but I guess Microsoft has better programmers.
oliv__ 10y ago
After trying it out, I feel like their implementation of scrolling might be an important factor. The editor scrolls significantly faster than my browser normally does.

by tiles 10y ago

Secretmapper 10y ago

Does Atom still feel slower? I've used Atom before and it did feel sluggish, and using VSCode for TypeScript really felt lightyears ahead from Atom. (maybe a bit unfair of a comparison since it's most likely nicely integrated for it, but whatever) To be fair I haven't caught up with their current versions (I'm a vimmer, I just tried them) but I think I tried Atom after the React move.

rattray 10y ago
Atom has gotten incrementally faster and I have few problems using it as my main editor at work, on a Macbook Pro with 16GB of RAM. It isn't pleasant to use on my personal laptop (MBA with 4GB RAM) where I frequently switch projects. While I am a happy Atom user, I am disappointed with performance; I think there's an order-of-magnitude jump in overall speed that the editor could really use.
- Loic 10y ago
  You are talking about 16 GB of RAM, rights? My emacs is very happy with 32 MB of RAM and my vim with even less. I understand that Atom is doing a lot, but if you need 16 GB of RAM to run your text editor, this simply means that the developers have not been using the right data structures to manage the state of the application or maybe the new code editors have an implementation of an AI coding for you so you can outsource yourself.
  - Longhanks 10y ago
    That's the price you pay for Electron.
    - rattray 10y ago
      The reason we're talking about Atom on this thread is because VSCode, which also uses electron, does not have performance issues.
      - vortico 10y ago
        Which makes me think, Atom is giving Electron a really bad reputation for its speed. Sure, it consumes tons of RAM, but it's not that slow by default.
  - rattray 10y ago
    Many people use full IDE's to do their work - JetBrains, VS, etc - which are dramatically more resource intensive than Atom.
    - siddhant 10y ago
      Yes but they are IDEs, while Atom/Vim/Emacs are plain text editors.
      - teacup50 10y ago
        ... and Emacs really is an IDE; the distinction between it and GUI IDEs has more to do with user interface than any limitation of Emacs. e.g. live libclang-based code completion for Emacs: https://github.com/Sarcasm/irony-mode https://github.com/Sarcasm/irony-mode
        adrusi 10y ago
        Atom is essentially the same class of editor as emacs. Both have designs that can accomodate IDE features (so does vim, but it's more of an afterthought in that case), but normal usage is not IDE-like. Atom is essentially emacs built atop javascript+web rather than lisp+unix.
        fallenshell 10y ago
        This is more holy war material than anything really. Emacs is just an editor.
      - daigoba66 10y ago
        > plain text editors I don't think that's a fair assessment given the what is now minimum expectations around syntax highlighting, syntax/grammar validation, autocomplete, etc. We're no longer dealing with "plain text".
        cyphar 10y ago
        So that's even less of an excuse for Atom's resource hogging. Vim and neovim use so little memory and are probably the most responsive editors I've ever used.
  - rkangel 10y ago
    I was going to say that my emacs uses an awful lot more memory than that, but actually it's got 190 files open in at least 3 languages and it's using 89.8 Mb of RAM at the moment. Atom is at a fundamental disadvantage - it's built on a much more complicated and abstracted stack of technologies. Javascript engines do spectacular things these days but they have a harder job to do than executing compiled lisp, and that's before you look at the whole of the rest of the stack involved.
  - toomanybeersies 10y ago
    And to think people used to say emacs stood for Eight Megabytes And Constantly Swapping.
    - ank_the_elder 10y ago
      And let's not forget: Editor for Middle Aged Computer Scientists Escape-Meta-Alt-Control-Shift Tt's still my favourite, though.
  - fallenshell 10y ago
    I've been an avid Sublime user for many years and still am, and this is what puts me off any electron based editor or app in general. The requirements for the most trivial things are so high, it is insane. Try running Atom on a AMD E1 laptop. TLDR, not very nice.
  - bbcbasic 10y ago
    It's new paradigm - bloatier than an IDE, as slow as a web page but without the advantage of storing / running anything i n the cloud.
- caconym_ 10y ago
  Last time I seriously tried using it, it seemed unnecessarily CPU-hungry and my battery life suffered as a result. That fact alone was enough to get me to stop using it. I have a weird thing about inefficient software in general, but in this case its inefficiency was actually inconveniencing me. With my good old Vim+tmux workflow, my 12" Macbook claims it'll go for 14-15 hours, though I haven't ever fully tested that claim.
- toomanybeersies 10y ago
  I used Atom for 3 months over New Year's on a 4 GB 2015 MBA. I had no issues whatsoever. Interestingly enough, Atom seems to really struggle on my Windows laptop, it's often incredibly choppy. It actually runs better in a Linux VM than natively on Windows.
  - SOLAR_FIELDS 10y ago
    The only consistent issue that I have had with Atom since I started using it in late 2014 was the handling of large files. It has gotten incrementally better, as others have stated, but trying to open up, for instance, a JSON file larger than 10-20 megabytes in the editor causes the editor to be brought to a grinding halt.

JoeCoder_ 10y ago

From the FAQ. https://github.com/Microsoft/monaco-editor#faq https://github.com/Microsoft/monaco-editor#faq: "Why all these web workers and why should I care?" "A: Language services create web workers to compute heavy stuff outside the UI thread. They cost hardly anything in terms of resource overhead and you shouldn't worry too much about them, as long as you get them to work (see above the cross-domain case)." Maybe that's part of the reason?

amasad 10y ago
I think that's pretty much standard practice. I'm not sure about Atom but Ace leverage's workers for linting, intellesense and things like that.
- c-smile 10y ago
  Educated guess: generator functions with chunked processing on setInterval callbacks would be less CPU consuming for such tasks.
  - EGreg 10y ago
    Pretty sure setInterval still uses the same processor core, wasting the others

alexdima 10y ago

Hi, I'm working on the editor since almost 5 years now. Phew, time flies. There is no silver bullet, we mostly try to keep all computations limited to the viewport size (if you have 20 lines visible, then typing, colorizing, painting a frame, etc. should all end up being computed with loops covering those 20 lines and not the entire buffer size). We also use extensively the profilers, and most recently (last month) I learned about this great tool called IR Hydra[1]. The gains from eliminating bailouts in the hot code paths are probably too small to notice (5-10% per render), but I like to think that everything adds up. We use translate3d for scrolling (except in Firefox which has a known bug[2]) and that brings down the browser painting times considerably when scrolling. I've also found insertAdjacentHTML to be the fastest way to create dom nodes (from big fat strings) across all browsers. Sort of silly to mention, but we use binary search a lot :). [1] http://mrale.ph/irhydra/2/ http://mrale.ph/irhydra/2/ [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1083132 https://bugzilla.mozilla.org/show_bug.cgi?id=1083132

tiles 10y ago
Thanks for this. :) Learning the type of tricks needed to get DOM performance are hard-won, I imagine, so hearing it straight from a developer is extremely valuable to me.
alexdima 10y ago
Forgot to mention a funny fact I found. Minify everything [1] [1] https://top.fse.guru/nodejs-a-quick-optimization-advice-7353b820c92e#.nfvi89hjc https://top.fse.guru/nodejs-a-quick-optimization-advice-7353...
- vanderZwan 10y ago
  > v8 optimizer (crankshaft) inlines the functions whose body length, including the comments, is less than 600 characters. In what kind of world is that a sensible metric to decide if a function can be inlined?
  - luckystarr 10y ago

c-smile 10y ago

The editor is essentially a virtual list - sliding buffer of DOM elements - only visible lines are represented in the DOM. That's probably the only reasonable way of doing such editors effectively in modern browsers. Drawback of this approach: hard to integrate platform scrollbar to that, quite a lot of JS code to support virtualization, etc. Speaking about syntax/text highlighting in HTML ... In Sciter I've added an option [1] to mark character runs without creating tons of heavy weight DOM elements (The Monaco uses <span>'s for that). Plus an option to style those run marks in CSS: plaintext > text::mark(keyword) { color: blue; } plaintext > text::mark(symbol) { color: brown; } Editor's DOM model in Sciter's case is a flat list of <text> elements representing each line. <plaintext> <text>first line</text> <text>first line</text> ... </plaintext> In fact such marks are needed not only for syntax colorizing but for other things like misspelling highlighting, text found highlighting and other cases where you need to highlight text but DOM change is highly non-desirable. [1] Tokenizer + ::mark() = syntax colorizer : http://sciter.com/tokenizer-mark-syntax-colorizer/ http://sciter.com/tokenizer-mark-syntax-colorizer/

xuejie 10y ago
Not an expert here so I might be wrong, but I've been reading about Framework7(http://framework7.io/ http://framework7.io/) lately, which uses both virtual list and native scrolling. So maybe you might not have to implement custom scrolling here? It could also be that mobile CSS has its own quirks so different implementation can be used, again, not a DOM expert here.
- c-smile 10y ago
  Check this: http://sergimansilla.com/blog/virtual-scrolling http://sergimansilla.com/blog/virtual-scrolling it is an example of virtual list showing 1,000,000 records with native browser's scrollbars. So "yes" it is doable in principle but with JS help of course. And yet only for items of the same height.

FuturePromise 10y ago

I sort of like Atom but it's way too slow, buggy, and quirky for me to love it. I'm looking forward to trying Monaco. You'd think it would have the same problems being javascript-based, but I guess Microsoft has better programmers.

oliv__ 10y ago

After trying it out, I feel like their implementation of scrolling might be an important factor. The editor scrolls significantly faster than my browser normally does.