What were you doing with it that gave you performance problems? Basic navigation has millisecond response time. Auto-complete / live syntax checking for Python is instantaneous.
My peeve is with font rendering. The same fonts look better in pycharm. I hope they improve this.
Similar real line: Does it still eat battery like a mid-westerner at a buffet?
I've thought about using underlying tech for a desktop app. I don't know how easy it will be to sell given that it would drain battery at probably 1.5 the rate of a normal Java or QT app.
250mb of RAM for a chat app that can display 4k assets, renders every known written language under the sun side-by-side in multiple fonts, supports a stupid number of emoji, has an inline image viewer, realtime sockets kept open for notifications, includes syntax highlighting for a bunch of languages, a wysiwyg-ish editor for posts, one-on-one audio chat, and can work effortlessly with hundreds of people in a single channel (which is about as many as i've seen, but it could do more).
I think that's more than reasonable, and trying to get that number down to anything lower would be such a waste of resources for almost no payoff (what percentage of users do you think will have their lives measurably improved by having slack use 100MB less RAM?)
Oh, and mine is only using 100MB and has been running for a few days at least.
>250mb of RAM for a chat app that can display 4k assets, renders every known written language under the sun side-by-side in multiple fonts, supports a stupid number of emoji, has an inline image viewer, realtime sockets kept open for notifications, includes syntax highlighting for a bunch of languages, a wysiwyg-ish editor for posts, one-on-one audio chat, and can work effortlessly with hundreds of people in a single channel
Not of what you wrote is even remotely difficult to be achieved, even in a 50MB-using native app.
In fact most of those things come for free with the OS and relevant native libs are already loaded into memory:
"renders every known written language under the sun side-by-side in multiple fonts", "supports a stupid number of emoji" (the OS font-renderer can give all that to all apps for nearly free)
"can display 4k assets", "has an inline image viewer" (I can do that in a trivial app that's 1MB or less).
"includes syntax highlighting for a bunch of languages" ...
Really, none of these features, and neither all of them combined, warrant 250mb of RAM.
But again, would it really make any significant difference in the vast majority of users?
If slack had taken the time to devote another team to developing another application (because they still need to support the web), possibly multiple applications for each platform, would they be where they are today?
Would that time and money pay off in any way? I really believe it wouldn't. To save a few hundred mb of RAM, you are looking at triple or quadruple your development and maintenance costs, not to mention making it that much more costly to add new features. That doesn't seem like a good payoff.
Obviously in places where it did make a difference (mobile platforms) they went completely native, and it shows in both the positive and the negative. Their mobile apps look and feel native, and work quite well, but they lag behind the "web based" clients in features. (most notably the new voice chat options are not in the mobile versions)
In a perfect world every application would be custom developed for each and every platform, and no expense would be paid to ensure that there are 0 wasted resources, but we are far from a perfect world.
Having a slack app that runs on any desktop platform, feels the same between all of them, and allows Slack as a company to exist is a win in my book, even if it uses a few hundred mb more than it should (which again, for me it only uses 100mb of ram, that's 1/320th of my total ram on this machine, and only like 40mb more than the tab that i'm writing this comment on is taking).
>Would that time and money pay off in any way? I really believe it wouldn't. To save a few hundred mb of RAM, you are looking at triple or quadruple your development and maintenance costs, not to mention making it that much more costly to add new features. That doesn't seem like a good payoff.
I don't think writing native apps is so much more difficult that a web app like Slack. If anything, it's probably the opposite.
There are cross-platform (native) apps with custom UIs, like DAWs and NLEs that are an order of magnitude more complex in both their UI and their logic code, and yet are done with teams and by companies that have an order of magnitude less funding than a company like Slack.
It might not be more difficult, hell it is probably easier for each individual platform, but even if each one is 20% quicker than a web based one, all together you would end up spending 240% as much.
Plus then there is ongoing maintence costs, probably a ton more documentation costs (unless they all look and act the same), more coordination needed with new features to ensure parity, and more bugs and security issue surface area.
That's not a trade-off I'd want to make unless it was required for some other reasons.
I'm not particularly familiar with the relative costs of native vs Electron, but it should be noted that: a) many DAWs are single-platform; b) DAWs don't have backends, which is at least a significant portion (if not the majority) of what a service like Spotify or Slack spends development time on.
There's no doubt both of them are not resource-effective at all, especially compared to other apps made in other tech stacks.
However, both are pretty successful services, and since the parent comment expressed concern if an Electron app "would sell", these are examples that such apps are comercially viable (even with all the problems they have).
At the very least, one can use them to go to market faster and/or validate an idea. I do hope that Electron (or other similar techs) apps reach a point where they are viable long-term in terms of performance and battery-efficiency. I also dislike slow, memory-hungry and battery-draining apps as much as pretty much anyone, but one should not dismiss Electron as useless.
I think it's unlikely the performance issues are related to the underlying tech (that is, Electron), since it's basically a custom build of Chromium that omits the normal web browser controls. Performance-wise, if your app is suitable for running in a browser, it should be fine for bundling with Electron.
As noted in a sibling thread, other Electron apps such as Spotify and Slack do suffer from performance issues, and the general notion is that Electron apps are "slow by default" - that is, slow unless you take explicit effort to make them fast.
Since when are programming editors handling large files and IDE-like features "suitable for running in a browser"?
I know there have been several (browser based programming editors) over the years, but all have been equally crappy and slow on medium to large files, and not that better at normal workflows either.
not sure, but i think for buffet restaurants on the coast, "all you can eat" is at the customer's discretion; it's not a legal requirement like it is in the MidWest
At least moving around tabs is fast now. Other than that I feel Atom is pretty fast on my computer. Still some problems with large files compared to VSCode but I still like Atom more.
Nothing "earthshattering" in either of these releases. But progress is definitely being made.
I have nothing to really back this up, but it looks like they are in the "death by 1000 cuts" mode of trying to speed things up. Little improvements here or there, little speedups across the board, refactoring bits of code to skip processes that aren't necessary when possible. Those kinds of things. If you are waiting for a big event like "hey we did X and now it's 5x faster across the board" i don't think you are going to see it any time soon (and if it does happen, you can be sure it'll be in the title!).
That being said, this release does bump the node version up, and the npm version. A lot of the startup slowness is from finding and loading node modules (at least from the bit of profiling I did months ago), and NPM3's flatter structure should allow maximum "reuse" of modules meaning less time reparsing identical modules.
I don't know if this will have any actual visible changes, but again, death by 1000 cuts.
I don't think it is, this is the only thing I'm interested in hearing from Atom. Every time I've tried it has been unusable to me, I need it to be at least close to Sublime performance and resource usage to matter.
There are still little things that I notice are slow. For example, when I search for text within a file, I hit Cmd-f, then paste whatever I'm searching for.. And then my previous search finally loads and overwrites my actual search. In other words, I'm quicker at pasting than the editor is into the search window, so I have to deliberately slow down my paste.
I'm actually trying VisualStudio Code now, mostly because Atom handles indentation terribly. Trying to copy and paste and preserve indentation is a lost cause as of now.
I use it daily for PHP development, and I don't ever notice performance slow-downs unless I accidently click on a >1mb image and it tries to write the binary to display.
One thing I just tried: opening a bundle.js file. I accidentally do this at least once a day and it crashed Atom every time. The 1.11 beta handles it fine now. Good job Atom people!
That's the worst suggestion possible. It is the reason why why developers do not even notice that their program/application/page uses one or two orders of magnitude more resources than it needs and thus will bring many users' machine to its knees and run way slower than it should.
Since I am not going to follow the upcoming conversation, I sum it up in advance:
* [Insert here the usual "yes, but nowadays everyone has got X Go RAM, and a CPU scoring YYY WhateverMark." ]
* That's not true by any means, in real life most non-geek people do not have these or want to buy them (even if "every computer sold nowadays comes with it" was true, which it isn't either) just to do everything that they could already do 10 years ago, but in fuchsia now; and even people with an up-to-date machine may wish to run several different programs or several instances of the same application in these days without eating all their RAM, maxing their CPU or draining their battery.
> > Developers and designers need high end machines
> Explain to me why you need an i7 as a dev but the consumers using your product don't need an i7 to run the exact same thing.
Because dev tools take resources that the product doesn't take on the end user machine while running in delivered form.
Whether that's compile/build tools, whether that's running server and client simultaneously on a dev machine, whether that's running code in debug form under debugger rather than "naked" in delivered form, or whether that's just the power to run the code itself alongside an IDE, there's all kinds of reasons why a dev machine needs more than is required for an end user of the code being developed.
Similar, overlapping, but not exactly identical concerns apply to "designers" as opposed to "developers".
You can add them for things like syntax highlighting, but they can do so much more, and in many cases can border on "IDE-level" features.
Things like autocomplete, code linting, smart refactor tools, find reference/definition, test runners, debuggers, git integration, and a ton more. (one that I use a lot adds a terminal in the browser so I can run some command line tools without having to tab away to something else)
They are pretty limitless. If it can be rendered via HTML/css/js, it can be a plugin.
Why? 1.9->2.0 would not make sense in most release schemes. Most release schemes are major.minor, so incrementing the major number implies a MAJOR change. So major that it is probably not backwards compatible with the 1.X versions.
Using groups of numerals separated by decimal points to communicate this not-decimal nature is, however, a potentially very confusing overloading of notation (and, actually, while most version numbers using notation that looks like that now don't have decimal number semantics, that's not historically universally true; version numbers that were -- at least to the extent of comparing as -- decimals were actually quite common in the past.)
And still are in some contexts, but that creates its own confusion. Developers reserved 2 digits for the minor revision. So what happens at 1.99 when they realize they don't want to go to 2.00 (perhaps 1.99 was a bug fix for the legacy system and 2.xx is already out there).
If you want to use a decimal-imitative notation, do like Knuth and have your system's version number converge to Pi or e or some other constant.
This is pretty typical for most open source projects. The major version will rarely get bumped unless the devs feel that it is a significant update (or they have some predefined meaning of bumping a major version, like breaking APIs).
A little off topic, but that got me thinking... Is there actually any major software that is still using decimal version numbers? So that, for example, 1.1 < 1.12 < 1.2?
Wikipedia [1] says it was common in the 1980s, but gives two only two modern examples: Opera and Movable Type. And even that seems to be outdated. Neither of them uses decimal version numbers any more. Can you think of any others?
For many projects, lots of consumers may not realize the project under development is using semantic versioning until they cross a decimal threshold like this and only then if they take care to notice the progression of version numbers.
I had long preferred either Real/decimal numbers as version numbers or hierarchy-of-decimal-digits (exactly one digit each, e.g. "1.9.9" must progress to something like "1.9.9.1" or "2.0.0"). But semantic versioning is really popular these days, so I'm much less surprised even if it's not my preference.
Obligatory: Please stop trolling atom on performance. Have set up several dev teams on atom + eslint. Finishing up my own product now, 170K LOC react-native app, 7K LOC api code. All written on atom. One thing it hasn't done noticeably till now is lag.
The only times I see a hit on perf is when I run react-native server, genymotion emulator, chrome, and android studio along with atom. But then, I see a perf hit on everything at these times.
Even emacs completely shits the bed when it comes to long lines. I love it, but there are things about every tool that requires tradeoffs. I'm willing to deal with bad performance due to decades old technological decisions, in order to gain (to me) unparalleled editing and customization.
That's sort of true, but OTOH vi, Emacs and even Notepad++ can write code and view huge log files. People who are holding out on Atom because of speed maybe don't want two tools where one will do, which is perfectly reasonable.
Just move on man. I used to be a big hater of Atom, but then I realized that I was not contributing on its development so I stopped being a "hater" and continue with my own life using another editor that actually works for my use case. As the parent comment says, Atom works for some people and that is enough for them to continue its development, I am fairly confident that it will never have the performance that a native editor has but it is workable as long as you don't do resource intensive tasks.
My computer is not powerful at all so Atom is obviously slow as hell and lags all the time, at first I thought I improved my typing skills because I was typing faster than the editor was displaying the characters, but that was obviously not the case. Most Atom users — or at least the most active users — use rMBPs with i7 CPUs and (maybe?) 16GB of RAM, I don't want to buy a computer like that just to use a code editor like this, I would do it for an IDE though; and even if I had a computer like this I would not want to give most of its resources to the code editor when there are more important things to spend the CPU / RAM on.
If your intention is to open a database dump then use a different tool, a proper log viewer or something like that, I don't even understand why would you want to use a code editor — even with good performance — to inspect a DB dump in the first place.
Having never heard of Atom before this, I appreciate the notice that it is not a suitable replacement for a general-purpose editor like vim. Saved me who-knows-how-many hours of frustration.
Database dump and log files are just good example of potentially big text files. They should be usable in any text editor. Not looking at the issue is not a good way to build software.
I think nobody is really an atom hater. Usually it goes more like "I really want to love Atom so much, but I'm still concerned about it's performance and stability".
Mentioning whether a piece of software is noticeably slow for its primary use case is not "trolling" by any definitely of the word. It's a legitimate issue and deserves to be mentioned for anyone considering it as an option for their development setup.
i have a late 2012 macbook pro 13' w/ i7 2.9ghz, 8gb ram for work. this isn't exactly a high-end device, nor a low-end one but i would say this laptop is pretty common.
atom runs slow for me. just too frustrating to use even though i would like to use it (even despite reporting bugs that essentially get left to die). sublime just runs faster.
People are not "trolling" atom on performance. They are bringing up valid concerns.
Atom runs fast enough on my MBP, but I could never get the packages and plug-ins to consistently play nicely with the corporate proxies and firewalls at my current employer. So, I gave it up in favor of Visual Studio Code. The updates and plug-in installations for Code simply Just Work.
I'm an avid user of Atom, but one thing I'm curious about regarding the performance issues (which I primarily see on startup) is whether or not the JIT compilation done by V8 (which is what it uses behind the scenes) does any caching of generated code that lasts beyond a single program launch.
JavaScript JITs are designed with interpretation first in mind, and then optimised native code generation for hotspots. This works pretty well for apps loaded irregularly, but I'm wondering if it happens for apps based on Electron (of which Atom is an example)?
“There are only two kinds of languages: the ones people complain about and the ones nobody uses.”
― Bjarne Stroustrup, The C++ Programming Language
Same goes for Software, I love atom precisely because I can hack it into whatever I need it to be with knowledge I currently have as a Web developer. For that and that alone, Atom is awesome :)
cpu: i7-3770 CPU @ 3.40GHz
, ram: Patriot 16GB(2x8GB) Viper III DDR3 2133 (PC3 17000)
, ssd: Kingston HyperX 3K 240 GB SATA III 2.5-Inch 6.0 Gb/s Solid State Drive SH103S3/240G
, mb: ASUS P8Z77-V LGA 1155 Intel Z77 HDMI SATA 6Gb/s USB 3.0 ATX Intel Motherboard
Operating System: Ubuntu 16.04
My Atom performance report:
No lag nor unresponsiveness to report. Nav responds in milliseconds as does auto-complete and live Python syntax checking. I am using atom primarily for Python development.
Ok after reading comments about performance compared to sublime. I wanted to try this out myself.
I opened a 7.5K LOC on both atom and sublime, atom was responsiveness and no lag.
Second, I fired up my linux machine and filled a log file with 159K lines. I use vi first and no lag. I opened it on atom, it was slow, took more than 30 secs to basically show the file, not completely loaded. And finally, I opened that log file on sublime, bam! instant load, no lag.
So, yes, I can see what fellow HNers have been saying about the performance.
cpu: intel core i5 680 @ 3.60GHz,
Memory: DDR3 12G,
OS: Windows 10 Professional
FYI to anyone on Linux (may apply to other platforms too), the beta doesn't override your previous install anymore so if you had the 1.10 beta you need to uninstall that after because the 1.11 beta is `atom` and the 1.10 was `atom-beta`.
Atom is my main editor (actually I use Vim for git commit messages and for doing quick file editions). It may be unresponsive sometimes, but it is known, officialy recognized and actively being worked on.
The main reason I use Atom is because it is free as in freedom. Since Emacs and Vim no other free text editor has received so much effort. This makes me think that Atom will live for a very long time.
96 comments
[ 73.9 ms ] story [ 2877 ms ] threadApologies if this comes off as trolling. I really want it to be snappy so I can switch over.
My peeve is with font rendering. The same fonts look better in pycharm. I hope they improve this.
I've thought about using underlying tech for a desktop app. I don't know how easy it will be to sell given that it would drain battery at probably 1.5 the rate of a normal Java or QT app.
Also, I'm not sure why Slack needs ~250MB of RAM. Seems a bit extreme for a chat app.
Something is wrong when a chat app takes more RAM than my Vagrant VM running an entire OS!
I think that's more than reasonable, and trying to get that number down to anything lower would be such a waste of resources for almost no payoff (what percentage of users do you think will have their lives measurably improved by having slack use 100MB less RAM?)
Oh, and mine is only using 100MB and has been running for a few days at least.
Not of what you wrote is even remotely difficult to be achieved, even in a 50MB-using native app.
In fact most of those things come for free with the OS and relevant native libs are already loaded into memory:
"renders every known written language under the sun side-by-side in multiple fonts", "supports a stupid number of emoji" (the OS font-renderer can give all that to all apps for nearly free)
"can display 4k assets", "has an inline image viewer" (I can do that in a trivial app that's 1MB or less).
"includes syntax highlighting for a bunch of languages" ...
Really, none of these features, and neither all of them combined, warrant 250mb of RAM.
If slack had taken the time to devote another team to developing another application (because they still need to support the web), possibly multiple applications for each platform, would they be where they are today?
Would that time and money pay off in any way? I really believe it wouldn't. To save a few hundred mb of RAM, you are looking at triple or quadruple your development and maintenance costs, not to mention making it that much more costly to add new features. That doesn't seem like a good payoff.
Obviously in places where it did make a difference (mobile platforms) they went completely native, and it shows in both the positive and the negative. Their mobile apps look and feel native, and work quite well, but they lag behind the "web based" clients in features. (most notably the new voice chat options are not in the mobile versions)
In a perfect world every application would be custom developed for each and every platform, and no expense would be paid to ensure that there are 0 wasted resources, but we are far from a perfect world.
Having a slack app that runs on any desktop platform, feels the same between all of them, and allows Slack as a company to exist is a win in my book, even if it uses a few hundred mb more than it should (which again, for me it only uses 100mb of ram, that's 1/320th of my total ram on this machine, and only like 40mb more than the tab that i'm writing this comment on is taking).
I don't think writing native apps is so much more difficult that a web app like Slack. If anything, it's probably the opposite.
There are cross-platform (native) apps with custom UIs, like DAWs and NLEs that are an order of magnitude more complex in both their UI and their logic code, and yet are done with teams and by companies that have an order of magnitude less funding than a company like Slack.
Plus then there is ongoing maintence costs, probably a ton more documentation costs (unless they all look and act the same), more coordination needed with new features to ensure parity, and more bugs and security issue surface area.
That's not a trade-off I'd want to make unless it was required for some other reasons.
However, both are pretty successful services, and since the parent comment expressed concern if an Electron app "would sell", these are examples that such apps are comercially viable (even with all the problems they have).
At the very least, one can use them to go to market faster and/or validate an idea. I do hope that Electron (or other similar techs) apps reach a point where they are viable long-term in terms of performance and battery-efficiency. I also dislike slow, memory-hungry and battery-draining apps as much as pretty much anyone, but one should not dismiss Electron as useless.
I know there have been several (browser based programming editors) over the years, but all have been equally crappy and slow on medium to large files, and not that better at normal workflows either.
I mean, there's the odd one here or there, but compared to the last time I was in Kansas, they might as well not exist.
I have nothing to really back this up, but it looks like they are in the "death by 1000 cuts" mode of trying to speed things up. Little improvements here or there, little speedups across the board, refactoring bits of code to skip processes that aren't necessary when possible. Those kinds of things. If you are waiting for a big event like "hey we did X and now it's 5x faster across the board" i don't think you are going to see it any time soon (and if it does happen, you can be sure it'll be in the title!).
That being said, this release does bump the node version up, and the npm version. A lot of the startup slowness is from finding and loading node modules (at least from the bit of profiling I did months ago), and NPM3's flatter structure should allow maximum "reuse" of modules meaning less time reparsing identical modules.
I don't know if this will have any actual visible changes, but again, death by 1000 cuts.
I had numerous instances where Atom would crash at inopportune times on my 2015 16GB MBP.
I Really hope these core issues have been fixed. Seems like a great editor and I’d love to be able to give it another shot.
It still takes a while to launch, but that isn't as important to me as performance once it is running.
I'm actually trying VisualStudio Code now, mostly because Atom handles indentation terribly. Trying to copy and paste and preserve indentation is a lost cause as of now.
Yay, we can open a file!
But the new king is Atom. One reason is it easily plugs in the modern 'transpilers' / generators. Ex: jade. inteliJ is pita for jade.
i urge you to try the free atom.
I suggest an high end i7 for all developers, especially web dev/designers.
I suggest that too; unfortunately the company I work for gives us cheaper machines with AMDs to cut costs.
Since I am not going to follow the upcoming conversation, I sum it up in advance:
* [Insert here the usual "yes, but nowadays everyone has got X Go RAM, and a CPU scoring YYY WhateverMark." ]
* That's not true by any means, in real life most non-geek people do not have these or want to buy them (even if "every computer sold nowadays comes with it" was true, which it isn't either) just to do everything that they could already do 10 years ago, but in fuchsia now; and even people with an up-to-date machine may wish to run several different programs or several instances of the same application in these days without eating all their RAM, maxing their CPU or draining their battery.
Maybe pay developers more to the point where PC is cheaper.
This is simply not true. Explain to me why you need an i7 as a dev but the consumers using your product don't need an i7 to run the exact same thing.
> Explain to me why you need an i7 as a dev but the consumers using your product don't need an i7 to run the exact same thing.
Because dev tools take resources that the product doesn't take on the end user machine while running in delivered form.
Whether that's compile/build tools, whether that's running server and client simultaneously on a dev machine, whether that's running code in debug form under debugger rather than "naked" in delivered form, or whether that's just the power to run the code itself alongside an IDE, there's all kinds of reasons why a dev machine needs more than is required for an end user of the code being developed.
Similar, overlapping, but not exactly identical concerns apply to "designers" as opposed to "developers".
Web developers need to batch resize images to make them smaller.
Most developers are expensive and should not be paid to wait. But there are exceptions, some developers are not expensive.
You can add them for things like syntax highlighting, but they can do so much more, and in many cases can border on "IDE-level" features.
Things like autocomplete, code linting, smart refactor tools, find reference/definition, test runners, debuggers, git integration, and a ton more. (one that I use a lot adds a terminal in the browser so I can run some command line tools without having to tab away to something else)
They are pretty limitless. If it can be rendered via HTML/css/js, it can be a plugin.
Using groups of numerals separated by decimal points to communicate this not-decimal nature is, however, a potentially very confusing overloading of notation (and, actually, while most version numbers using notation that looks like that now don't have decimal number semantics, that's not historically universally true; version numbers that were -- at least to the extent of comparing as -- decimals were actually quite common in the past.)
If you want to use a decimal-imitative notation, do like Knuth and have your system's version number converge to Pi or e or some other constant.
See for example binutils and ld (2.27)
https://www.gnu.org/software/binutils/
Or rust (which is at version 1.11) or idris (0.12)
https://en.wikipedia.org/wiki/Rust_(programming_language)
https://en.wikipedia.org/wiki/Idris_(programming_language)
Wikipedia [1] says it was common in the 1980s, but gives two only two modern examples: Opera and Movable Type. And even that seems to be outdated. Neither of them uses decimal version numbers any more. Can you think of any others?
[1] https://en.wikipedia.org/wiki/Software_versioning
I had long preferred either Real/decimal numbers as version numbers or hierarchy-of-decimal-digits (exactly one digit each, e.g. "1.9.9" must progress to something like "1.9.9.1" or "2.0.0"). But semantic versioning is really popular these days, so I'm much less surprised even if it's not my preference.
The only times I see a hit on perf is when I run react-native server, genymotion emulator, chrome, and android studio along with atom. But then, I see a perf hit on everything at these times.
Atom is for writing code, not viewing logs. We have tail and syslog and a thousand other tools for that.
"Atom - A hackable text editor"
My computer is not powerful at all so Atom is obviously slow as hell and lags all the time, at first I thought I improved my typing skills because I was typing faster than the editor was displaying the characters, but that was obviously not the case. Most Atom users — or at least the most active users — use rMBPs with i7 CPUs and (maybe?) 16GB of RAM, I don't want to buy a computer like that just to use a code editor like this, I would do it for an IDE though; and even if I had a computer like this I would not want to give most of its resources to the code editor when there are more important things to spend the CPU / RAM on.
If your intention is to open a database dump then use a different tool, a proper log viewer or something like that, I don't even understand why would you want to use a code editor — even with good performance — to inspect a DB dump in the first place.
Database dump and log files are just good example of potentially big text files. They should be usable in any text editor. Not looking at the issue is not a good way to build software.
atom runs slow for me. just too frustrating to use even though i would like to use it (even despite reporting bugs that essentially get left to die). sublime just runs faster.
Atom runs fast enough on my MBP, but I could never get the packages and plug-ins to consistently play nicely with the corporate proxies and firewalls at my current employer. So, I gave it up in favor of Visual Studio Code. The updates and plug-in installations for Code simply Just Work.
JavaScript JITs are designed with interpretation first in mind, and then optimised native code generation for hotspots. This works pretty well for apps loaded irregularly, but I'm wondering if it happens for apps based on Electron (of which Atom is an example)?
At a glance, it looks like there were some issues: https://github.com/electron/electron/issues/169#issuecomment...
― Bjarne Stroustrup, The C++ Programming Language
Same goes for Software, I love atom precisely because I can hack it into whatever I need it to be with knowledge I currently have as a Web developer. For that and that alone, Atom is awesome :)
cpu: i7-3770 CPU @ 3.40GHz , ram: Patriot 16GB(2x8GB) Viper III DDR3 2133 (PC3 17000) , ssd: Kingston HyperX 3K 240 GB SATA III 2.5-Inch 6.0 Gb/s Solid State Drive SH103S3/240G , mb: ASUS P8Z77-V LGA 1155 Intel Z77 HDMI SATA 6Gb/s USB 3.0 ATX Intel Motherboard
Operating System: Ubuntu 16.04
My Atom performance report: No lag nor unresponsiveness to report. Nav responds in milliseconds as does auto-complete and live Python syntax checking. I am using atom primarily for Python development.
I opened a 7.5K LOC on both atom and sublime, atom was responsiveness and no lag.
Second, I fired up my linux machine and filled a log file with 159K lines. I use vi first and no lag. I opened it on atom, it was slow, took more than 30 secs to basically show the file, not completely loaded. And finally, I opened that log file on sublime, bam! instant load, no lag.
So, yes, I can see what fellow HNers have been saying about the performance.
cpu: intel core i5 680 @ 3.60GHz, Memory: DDR3 12G, OS: Windows 10 Professional
https://github.com/jhallen/joes-sandbox/tree/master/editor-p...
My newish X1 Carbon has 8gb of ram (soldered); this probably means a few Atom instances are enough to use all the RAM...
> In the next year we're focused on improving Atom's performance, collaboration features, and better responsiveness with our open source community.
> Things that might make you stand out include:
> •Demonstrable experience building lightning-fast desktop applications
> ..
The main reason I use Atom is because it is free as in freedom. Since Emacs and Vim no other free text editor has received so much effort. This makes me think that Atom will live for a very long time.