4 ms·
I prefer it to atom already on OSX. * handles multiple files well. atom ends up being too many tabs with no quick way to get to them * MRU file switching * s
by mmgutz 12y ago
I prefer it to atom already on OSX.
* handles multiple files well. atom ends up being too many tabs with no quick way to get to them
* MRU file switching
* shows side by side default v user settings
* launches must faster (which is strange since it is based on electron)
* JS debbuger
Can't wait to try the CoreCLR.
- Jare 12y agoI just tried a 100MB C++ file; it opened in 2 seconds, and navigated very fast. No syntax highlighting, however a 20MB C++ file did receive syntax highlighting in the background (took around 30 seconds to reach the bottom), with navigation still 100% fast and responsive. Right now, this thing blows the Atom editor out of the water in terms of performance. For plugins and breadth of available functionality, Atom is miles ahead of course.
- sidthekidder 12y agoIsn't there any way to analyze and get some of these speedups back upstream?
- Jare 12y agoI believe Atom are already writing a new backend for their text buffer backend, but that part of the code is unrelated to what VSCode uses. I imagine the very fact that VSCode exists and performs so well will be enough to finally make that work a top priority for the Atom team, but we'll see.
- billrobertson42 12y agoSeriously? A 100MB C++ file?
- Jare 12y agoFor stress testing, of course! I just replicated a ~25kb file 4096 times.
- stinos 12y agothis thing blows the Atom editor out of the water in terms of performance Idem for Sublime Text. Loading large files on Windows is a total disaster with ST. Which is a shame, it's a great editor on all fronts except loading of large (as in > couple of MB) files which is just something I happen to do quite a lot.