5 ms·
No, VSCode doesn't run great. Maybe compared to IntelliJ and Visual Studio, but far worse than sublime text and vim. I have ~2ms input latency using vim on xte
by chmln 8y ago
No, VSCode doesn't run great. Maybe compared to IntelliJ and Visual Studio, but far worse than sublime text and vim.
I have ~2ms input latency using vim on xterm. I doubt VSCode can ever achieve this kind of performance, simply due to the poor architectural decision of using electron and JavaScript.
- aidenn0 8y agoI still remember the days when users of various vi clones derided emacs as "Eight Megabytes And Constantly Swapping" and now a single gvim instance with no files open is 37MB emacs is 51MB and atom is 300MB. My actually running emacs with slime loaded in the middle of debugging a lisp application is 127MB, which is still smaller than a freshly opened atom instance.
- jcelerier 8y ago> a single gvim instance with no files open is 37MB emacs is 51MB and atom is 300MB. this does not really strike me as odd for emacs and vim - pretty sure that if you load them in a computer with a 640 by 480 screen in a 32-bit OS on IceWM it will be comparable to the olden days. On todays's 4k screens, just opening a window that takes half of your screen will alone cost a good dozen megabytes of RAM - and if your UI widgets do caching (they should, text rendering is expensive), then each of your widgets may allocate a pixmap too. When screens were 72 DPI and a button was 30 by 10 pixels it was fine... but nowadays you have to multiply all the values by at least 4. And the switch to 64bit has instantaneously doubled the size of all the data structures working with pointers - which is generally a lot in GUI apps since most are trees of widgets. In some of the apps I've been working on, the RAM hit of 64bit has been more than 30%, and sadly the world does not seem to accept the x32 ABI.
- loup-vaillant 8y agoWe could have 32-bit pointers with a bit of hacking: First, re-implement memory management on top of std::vector (or similar dynamic array): have your pointers be array indices; replace the `brk()` system call by the `resize()` method; reimplement `malloc()` on top of that. And voilà, you can have your 32-bit pointers. You can even go down to 16-bits for small enough arenas. (No, I'm not actually serious. Though we could imagine something similar on some new language.)
- jcelerier 8y ago> We could have 32-bit pointers with a bit of hacking: We can also have them with zero hacking since there is an existing ABI for 32 bits pointers in 64 bit mode: https://wikipedia.org/wiki/X32_ABI https://wikipedia.org/wiki/X32_ABI ; you get all the benefits of x86_64 mode (more registers, default support of SSE2 etc) for the memory usage level of x86 (and 4gb of accessible ram instead of x86 OSes's 2.something addressable gigabytes). I'm pretty sure that only specialized apps actually require >4gb of ram - most common utilities (e.g. shell, text editor, etc...) should really be compiled in x32 mode.
- loup-vaillant 8y agoMy, I didn't know about x32 mode. I'll keep that in mind, thanks.
- aidenn0 8y agoAnything that is going to mmap a file of 1GB or larger will probably want 64-bit addressing, which will include any document editor that is designed around mmap. That's somewhat specialized, but not as much as you might think.
- binomialxenon 8y agoGVim carries a lot of extra weight because of GTK. Vim without a GUI uses 2.6 MiB of its own memory and 5.3 MiB of shared memory on my system.