7 ms·

C++ doesn't give you asymptotic Big(O) algorithmic superpowers. No language does.

r-w 5y ago
We're talking about small, quick operations supporting a synchronous, interactive user interface here. When it comes to performance, asymptotics aren't everything.
- goldenkey 5y ago
  JS has Workers. VS Code uses them wisely. Other Electron apps? Not so much. Block the event loop in other languages and you'll also see shitty results..
  - xg15 5y ago
    Have fun implementing all the overhead just communicating with those workers. That's a serialisation pass, a serialisation pass and two event queues, all just so your application doesn't lock up.
    - goldenkey 5y ago
      https://developers.google.com/web/updates/2011/09/Workers-ArrayBuffer https://developers.google.com/web/updates/2011/09/Workers-Ar... For 10 years an ArrayBuffer has been able to be sent by reference but good effort on disinformation.
      - int_19h 5y ago
        You still need to serialize/deserialize to put your object graph into the array, no?
        goldenkey 5y ago
        Not if you use WebAssembly. You can simply pass an Array Buffer to be worked on, you postMessage it with transferable=true. transfer Optional An optional array of Transferable objects to transfer ownership of. If the ownership of an object is transferred, it becomes unusable in the context it was sent from and becomes available only to the worker it was sent to. You can compile JS itself or pretty much any other language to WASM using Emscripten or the other LLVM toolkits. Looking at VSCode, it appears they use this technique for some of the heavy lifting. JS is very performant if you know how to use this hybrid architecture. The C++ guys above are shitting all over JS when an Electron app can simply use C++ transpiled to WASM if they really wanted to. Electron isn't really for JS as a coding language. It is much more for the awesome cross-platform UI you get with HTML, CSS, and JS. A lot has been done to optimize rendering engines. The same techniques that render snappy web pages can be used within Electron. All the griping above is really just ignorance. https://github.com/microsoft/vscode/search?q=wasm https://github.com/microsoft/vscode/search?q=wasm https://github.com/microsoft/vscode/search?q=arraybuffer https://github.com/microsoft/vscode/search?q=arraybuffer https://developer.mozilla.org/en-US/docs/WebAssembly/Using_the_JavaScript_API https://developer.mozilla.org/en-US/docs/WebAssembly/Using_t... https://developer.mozilla.org/en-US/docs/Web/API/Worker/postMessage https://developer.mozilla.org/en-US/docs/Web/API/Worker/post...
        npigrounet 5y ago
        Why use C++ when JS is faster? VSCode proves that. It's orders of magnitude faster than old VS, has more features, uses less resources, etc.
        hoseja 5y ago
        Let's wait thirty years for the legacy to accrue and then compare weenies, shall we?
        npigrounet 5y ago
        In thirty years, every single codebase will have been re-written in JS.
jjoonathan 5y ago
Stacking abstractions is a great way to give yourself Big O problems. Fighting the height of the stack reduces them, and "Use C++" does tend to fight the height of the stack.
- goldenkey 5y ago
  C++ doesn't fight the stack more than any good JIT. In fact, it may be less capable in noticing ways to inline functions given that it's a statically compiled language. It's only current advantage with the stack is tail call optimization which is coming to V8 very soon. Funny that the C++ guy is talking about abstractions, where them V-Tables at?
  - Jensson 5y ago
    They talked about stack of libraries beneath you, not the execution stack. If an API call takes 10 microseconds because several "premature optimization is the root of all evil" abstractions in between then doing that just 10k times already nets you 100ms which is a very noticeable stutter. So with that limitation you are now forced to create elaborate data structures with caching etc to try to work around this slow API call. However doing the same querying in C++ without those abstractions where each call takes 10 nanoseconds means that you no longer have to try to create complex data structures to work around that slow API call, even if you do it a million times it would only take 10 milliseconds and maybe drop a frame.
    - npigrounet 5y ago
      Nowadays JS is as fast as C++, if not faster.
      - goldenkey 5y ago
        Let me respond for him. He meant abstraction as in "stack of dependencies." Because everyone knows that's what abstraction means, right?! Because we all know NPM is a disaster as opposed to C++ dependency management which doesn't even exist in a standard form. /s
gabrielhidasy 5y ago
The average electron program has very little data to work with and not a lot of hard algorithms to run, yet still feels sluggish, that's the main complaint here
- goldenkey 5y ago
  It's because of work done on the main thread when it should be done using Workers. More about the lack of proficiency with regard to understanding UI applications themselves. Block the event loop in another language and you'll also get a laggy irresponsive UI.
  - dont__panic 5y ago
    There are probably a lot of different reasons why Electron apps can get laggy and unresponsive when sloppily written. However, I notice a significant difference in responsiveness between VS Code and Sublime Text -- enough that I changed my workflow back to Sublime Text because the very slight latency difference annoyed me. So I do think there is a baseline difference between the frameworks used by those two apps that no amount of optimization can overcome. It's sort of like the acceleration difference between a truck and a sedan: sure, powerful trucks can sometimes out-accelerate anemic sedans. But if you put a similar drivetrain in both vehicles, the vehicle with less mass (or memory footprint, in the framework analogy) is going to win.
howinteresting 5y ago
The big thing they don't tell you in CS class is that constant factors matter far more than asymptotic complexity most of the time. (There are a few exceptions though.)
- leetcrew 5y ago
  a text editor (especially for code) is a good example of a case where both matter. it doesn't take much latency to make typing a very frustrating experience. the common case (editing small files) needs to be very fast. but we also need to gracefully handle very large files that involve nontrivial processing (10kloc+ c++ files do unfortunately exist). I gave up on atom several years ago when it slowed to a crawl opening a 4kloc c file. vs code can handle many multiples of that without breaking a sweat, so it's my current first choice.
- goldenkey 5y ago
  Not in the case of a text editor. But feel free to hand-code your editor in assembly.
npigrounet 5y ago
Not even Rust?
- goldenkey 5y ago
  Perhaps if one truly transforms into a Rustacean.. ;-)

r-w 5y ago

We're talking about small, quick operations supporting a synchronous, interactive user interface here. When it comes to performance, asymptotics aren't everything.

goldenkey 5y ago
JS has Workers. VS Code uses them wisely. Other Electron apps? Not so much. Block the event loop in other languages and you'll also see shitty results..
- xg15 5y ago
  Have fun implementing all the overhead just communicating with those workers. That's a serialisation pass, a serialisation pass and two event queues, all just so your application doesn't lock up.
  - goldenkey 5y ago
    https://developers.google.com/web/updates/2011/09/Workers-ArrayBuffer https://developers.google.com/web/updates/2011/09/Workers-Ar... For 10 years an ArrayBuffer has been able to be sent by reference but good effort on disinformation.
    - int_19h 5y ago
      You still need to serialize/deserialize to put your object graph into the array, no?
      - goldenkey 5y ago
        Not if you use WebAssembly. You can simply pass an Array Buffer to be worked on, you postMessage it with transferable=true. transfer Optional An optional array of Transferable objects to transfer ownership of. If the ownership of an object is transferred, it becomes unusable in the context it was sent from and becomes available only to the worker it was sent to. You can compile JS itself or pretty much any other language to WASM using Emscripten or the other LLVM toolkits. Looking at VSCode, it appears they use this technique for some of the heavy lifting. JS is very performant if you know how to use this hybrid architecture. The C++ guys above are shitting all over JS when an Electron app can simply use C++ transpiled to WASM if they really wanted to. Electron isn't really for JS as a coding language. It is much more for the awesome cross-platform UI you get with HTML, CSS, and JS. A lot has been done to optimize rendering engines. The same techniques that render snappy web pages can be used within Electron. All the griping above is really just ignorance. https://github.com/microsoft/vscode/search?q=wasm https://github.com/microsoft/vscode/search?q=wasm https://github.com/microsoft/vscode/search?q=arraybuffer https://github.com/microsoft/vscode/search?q=arraybuffer https://developer.mozilla.org/en-US/docs/WebAssembly/Using_the_JavaScript_API https://developer.mozilla.org/en-US/docs/WebAssembly/Using_t... https://developer.mozilla.org/en-US/docs/Web/API/Worker/postMessage https://developer.mozilla.org/en-US/docs/Web/API/Worker/post...
        npigrounet 5y ago
        Why use C++ when JS is faster? VSCode proves that. It's orders of magnitude faster than old VS, has more features, uses less resources, etc.
        hoseja 5y ago
        Let's wait thirty years for the legacy to accrue and then compare weenies, shall we?
        npigrounet 5y ago
        In thirty years, every single codebase will have been re-written in JS.

jjoonathan 5y ago

Stacking abstractions is a great way to give yourself Big O problems. Fighting the height of the stack reduces them, and "Use C++" does tend to fight the height of the stack.

goldenkey 5y ago
C++ doesn't fight the stack more than any good JIT. In fact, it may be less capable in noticing ways to inline functions given that it's a statically compiled language. It's only current advantage with the stack is tail call optimization which is coming to V8 very soon. Funny that the C++ guy is talking about abstractions, where them V-Tables at?
- Jensson 5y ago
  They talked about stack of libraries beneath you, not the execution stack. If an API call takes 10 microseconds because several "premature optimization is the root of all evil" abstractions in between then doing that just 10k times already nets you 100ms which is a very noticeable stutter. So with that limitation you are now forced to create elaborate data structures with caching etc to try to work around this slow API call. However doing the same querying in C++ without those abstractions where each call takes 10 nanoseconds means that you no longer have to try to create complex data structures to work around that slow API call, even if you do it a million times it would only take 10 milliseconds and maybe drop a frame.
  - npigrounet 5y ago
    Nowadays JS is as fast as C++, if not faster.
    - goldenkey 5y ago
      Let me respond for him. He meant abstraction as in "stack of dependencies." Because everyone knows that's what abstraction means, right?! Because we all know NPM is a disaster as opposed to C++ dependency management which doesn't even exist in a standard form. /s

gabrielhidasy 5y ago

The average electron program has very little data to work with and not a lot of hard algorithms to run, yet still feels sluggish, that's the main complaint here

goldenkey 5y ago
It's because of work done on the main thread when it should be done using Workers. More about the lack of proficiency with regard to understanding UI applications themselves. Block the event loop in another language and you'll also get a laggy irresponsive UI.
- dont__panic 5y ago
  There are probably a lot of different reasons why Electron apps can get laggy and unresponsive when sloppily written. However, I notice a significant difference in responsiveness between VS Code and Sublime Text -- enough that I changed my workflow back to Sublime Text because the very slight latency difference annoyed me. So I do think there is a baseline difference between the frameworks used by those two apps that no amount of optimization can overcome. It's sort of like the acceleration difference between a truck and a sedan: sure, powerful trucks can sometimes out-accelerate anemic sedans. But if you put a similar drivetrain in both vehicles, the vehicle with less mass (or memory footprint, in the framework analogy) is going to win.

howinteresting 5y ago

The big thing they don't tell you in CS class is that constant factors matter far more than asymptotic complexity most of the time. (There are a few exceptions though.)

leetcrew 5y ago
a text editor (especially for code) is a good example of a case where both matter. it doesn't take much latency to make typing a very frustrating experience. the common case (editing small files) needs to be very fast. but we also need to gracefully handle very large files that involve nontrivial processing (10kloc+ c++ files do unfortunately exist). I gave up on atom several years ago when it slowed to a crawl opening a 4kloc c file. vs code can handle many multiples of that without breaking a sweat, so it's my current first choice.
goldenkey 5y ago
Not in the case of a text editor. But feel free to hand-code your editor in assembly.

npigrounet 5y ago

Not even Rust?

goldenkey 5y ago
Perhaps if one truly transforms into a Rustacean.. ;-)