3 ms·

They added an option at "Settings > Core" to "Warn before opening files larger than this number of megabytes". I don't use Atom at all, but after so much discus

They added an option at "Settings > Core" to "Warn before opening files larger than this number of megabytes". I don't use Atom at all, but after so much discussion about this issue I don't think there is a better solution. This clearly shows the difference in performance of a web-based text editor versus one built on top of a native UI library, but people prefer to sacrifice that performance for the nice interface and the extensibility, I suppose that many of these happy Atom users don't work on huge projects like some of us do, Atom works okay for what it offers.

brazzledazzle 10y ago
Visual studio code is a web based text editor is it not?
- JorgeGT 10y ago
  Specifically based on Electron, Atom's own framework: http://electron.atom.io/ http://electron.atom.io/
  - dismantlethesun 10y ago
    What is VS Code doing differently to make it so performant? Is it simply less extendible?
    - brazzledazzle 10y ago
      My understanding is that the editor portion of it was created specifically for Visual Studio Online and it had a smart and dedicated team (acquire hire maybe?) working on it.
- thewhitetulip 10y ago
  They have released the core part of VSCode as a node package called Monaco.
apetresc 10y ago
I don't think "huge projects" factors into it at all, no reasonable source file should ever come anywhere close to the Atom file size limit. If you have 13MB source files you have more serious problems than your choice of text editor. The kind of files that choke Atom are large data files that there are usually better/different tools for, that have very different requirements from code editing. And that has little to do with the relative huge-ness of your projects.
- SOLAR_FIELDS 10y ago
  I regularly deal with this problem because my use case demands viewing huge JSON files of size > 20 MB with lines of text that can exceed tens of thousands of characters (WKB polygons). You can argue that Atom is not suited to this particular use-case (and I would agree), but what can we do to make it better? I'm very curious as to the specific aspects of Electron/Atom that make this kind of operation slow and would be willing to contribute to make it faster. It's already been proven that Javascript can be fast for this kind of thing. So there is something in the infrastructure that can be improved.
- rayiner 10y ago
  It's not unusual to have things like compilers that generate big intermediate C files. Editors programmed using same technologies handled them just fine decades ago.
- flukus 10y ago
  It's a text editor, not a source code editor. Log files can be that big, as well as a bunch of other things, like csv's.
- glenndebacker 10y ago
  It's not only huge files that it's chocking on. Last year I was working on a game demo under time constraints and to cut a corner I base64 encoded a bitmap font. Every time I opened that 32KB file it began to slow down because that one big line. That being said I still use atom daily but not one big files or ones that contain big lines.

brazzledazzle 10y ago

Visual studio code is a web based text editor is it not?

JorgeGT 10y ago
Specifically based on Electron, Atom's own framework: http://electron.atom.io/ http://electron.atom.io/
- dismantlethesun 10y ago
  What is VS Code doing differently to make it so performant? Is it simply less extendible?
  - brazzledazzle 10y ago
    My understanding is that the editor portion of it was created specifically for Visual Studio Online and it had a smart and dedicated team (acquire hire maybe?) working on it.
thewhitetulip 10y ago
They have released the core part of VSCode as a node package called Monaco.

apetresc 10y ago

I don't think "huge projects" factors into it at all, no reasonable source file should ever come anywhere close to the Atom file size limit. If you have 13MB source files you have more serious problems than your choice of text editor. The kind of files that choke Atom are large data files that there are usually better/different tools for, that have very different requirements from code editing. And that has little to do with the relative huge-ness of your projects.

SOLAR_FIELDS 10y ago
I regularly deal with this problem because my use case demands viewing huge JSON files of size > 20 MB with lines of text that can exceed tens of thousands of characters (WKB polygons). You can argue that Atom is not suited to this particular use-case (and I would agree), but what can we do to make it better? I'm very curious as to the specific aspects of Electron/Atom that make this kind of operation slow and would be willing to contribute to make it faster. It's already been proven that Javascript can be fast for this kind of thing. So there is something in the infrastructure that can be improved.
rayiner 10y ago
It's not unusual to have things like compilers that generate big intermediate C files. Editors programmed using same technologies handled them just fine decades ago.
flukus 10y ago
It's a text editor, not a source code editor. Log files can be that big, as well as a bunch of other things, like csv's.
glenndebacker 10y ago
It's not only huge files that it's chocking on. Last year I was working on a game demo under time constraints and to cut a corner I base64 encoded a bitmap font. Every time I opened that 32KB file it began to slow down because that one big line. That being said I still use atom daily but not one big files or ones that contain big lines.