Visual Studio Code 是如何辦到高效處理大文件的？

01-02

根據如何評價 Visual Studio Code？下的一些回答， Visual Studio Code 處理大文件性能優異，打開文件迅速，編輯不卡頓，佔用系統資源低。但另一方面這個軟體又是基於 Chromium 的，按理說性能應該弱於原生 app ，為什麼會有這種看似不科學的事情發生？

我在和 Alexandru Dima 郵件討論漢字折行以及禁則（對，vim、ST 和 Atom 的斷行都有問題，VSC 搞不好會成我用過的第一個能正確斷行的編輯器……）的時候我問：為什麼不讓 NW 處理換行而是要自己計算，他給出了理由：

I initially implemented it like that.
But that made for a very slow/crashing editor when opening a minified file. Think something like 2 MB on a single line. Rendering 2 MB of source code into ~500K
dom nodes didn』t make browsers happy.

The wrapping is not correct, I can work on improving it, but a very large line does get virtualized such that only visible text in the viewport is rendered.

簡單來說就是：VSC 設計的時候考慮了打開大文件以及有超長行的文件，其編輯窗口只繪製可見的部分。不像 Atom……

我覺得還不夠高效。一個4M的無格式xml文件，reformat的速度比sublime的xml插件慢無數倍，讓我等到要殺進程。。。

遇到大文件直接顯示：

因為此文件是二進位文件，或文件過大，或使用了不受支持的文本編碼，將不會在編輯器中顯示。

那要看和誰比……

是基於webkit + nodejs(相當）的框架開發的，文件處理部分應該是用nodejs實現，這個就和原生一樣基礎了。