7 ms·
I've always felt like the inevitable conclusion of Atom and other electron based apps is the reversion to using low level compiled languages. I'm starting to g
by toomanybeersies 9y ago
I've always felt like the inevitable conclusion of Atom and other electron based apps is the reversion to using low level compiled languages.
I'm starting to get tired of how much of a resource hog Atom is.
- switchbak 9y agoIf it weren't for the oddness of the language, Lua would be a perfect fit. Near-C speeds, super flexible, no recompiles. You'd lose type safety compared to Rust, but they don't have that with JS now anyway. I don't think the majority of the memory consumption is from JS though, moreso the embedded browser+DOM approach. Edit: Blaming electron for bloat more than JS.
- pier25 9y ago> embedded browser+DOM And also Node.
- clnhlzmn 9y agoCheck out Textadept. It's an editor written largely in Lua.
- daurnimator 9y agoor Howl
- vvanders 9y agoI love Lua but VSCode is mostly written in TypeScript so you get a fair number type checks.
- flavio81 9y ago>If it weren't for the oddness of the language, Lua would be a perfect fit. Near-C speeds, super flexible, no recompiles. True. But there are also other dynamic languages that can go as fast as LuaJIT and of course faster than V8: Common Lisp and some Scheme implementations. Both are very elegant languages, moreso than Lua (which is very peculiar.) However, for the goals of an editor, my choice would be Free Pascal with Lazarus. It is already complete for cross-platform UI deployment. And compiled code is really fast.
- kfrzcode 9y agoAgreed.... running Slack + Atom + Chrome is enough to kill a < 4GB modern laptop. I'm on emacs and firefox for good.
- paultopia 9y agoFirefox has started sucking battery like crazy for me in the last few days, though. Can't figure out what it is.
- taneq 9y agoI thought it was the 'everything is super fast now' update (whichever one it was, 57 I think?) but maybe it's more recent than that. I was noticing last week that I can actually hear the CPU/GPU fans spinning up on some websites, which it never used to do.
- rukuu_001 9y agoAre you on a Mac? Had same, but fixed it with some prefs changes. Before that FF was stuck at 8-10% CPU.
- paultopia 9y agoYES YES what prefs changes were these? Please share!
- ahtu123 9y agoI'm always amazed when I see the size of the Atom executable on my computer(438MB). It's the size of a game! It's also pretty much the worst performing text editor (in runtime for most operations) and a memory hog. I really don't get the hype.
- paultopia 9y agoYeah, I wonder about how this Rust thing is going to work. I had always thought that the Atom perf problems didn't come from the underlying language but from the fact that it basically creates a massive DOM for every document... so how much is changing the backend language going to achieve?
- wmf 9y agoThey're also using WebGL instead of creating a massive DOM for every document. There are three kind of unrelated things here: Rust, CRDTs/collaboration, and WebGL so it may be hard to disentangle where the performance gains are coming from.
- deleted 9y ago[deleted]
- Sean1708 9y ago> it basically creates a massive DOM for every document From the OP: > In Atom, the vast majority of computation of any given frame is spent manipulating the DOM, recalculating styles, and performing layout. To achieve good text rendering performance, it is critical that we bypass this overhead and take direct control over rendering. Like Alacritty and Xi, we plan to employ OpenGL to position quads that are mapped to glyph bitmaps in a texture atlas.
- bitwize 9y agoI can't wait for my editor to get a Vulkan backend, for the utmost in text editing performance.
- nine_k 9y agoThe v8 engine behind Atom is an incredibly efficient compiler, a just-in-time compiler. Without it, all current JS interfaces would be comically slow. The problem with JS is that its execution model is built around highly dynamic features that are hard to compile efficiently. It also lacks a nice type system, though Typescript helps a lot. The problem with Atom performance, I suspect, is mostly with its using a web browser and DOM to exit text. I bet that elisp is seriously slower than JS on v8, but Emacs is faster than Atom, because its presentation layer is more efficient (while less capable).
- petre 9y agoMost of them are slower. Luajit is the only dynamic language runtime that's faster than V8, at least at prime number crunching. I haven't tested elisp but the others (Perl, Ruby etc.) are an order of magnitude slower.
- flavio81 9y ago>Luajit is the only dynamic language runtime that's faster than V8, Also Common Lisp (much faster than V8), Forth, and probably some Scheme implementations.
- nine_k 9y agoTo pick nits: Forth is not "dynamic"; words are called by their direct addresses, without any hashtable lookup. It's a stark contrast with Python, Ruby, JS, etc.
- klibertp 9y agoTo be fair, with CREATE/DOES> you can make them do any lookup you want easily. Well, as easy as anything in Forth.
- rattray 9y agoHmm, VSCode uses a web browser (and I think also the DOM) to display/edit text, and I find it to be perfectly snappy (Atom was unusably slow on my work codebase).