vscode編輯器打開大項目能夠快速預覽，這是如何做到的？軟體演算法比atom做的好?

01-04

同樣是基於瀏覽器開發的工具，vscode就要比atom的【性能】【流暢】【體驗】會好很多，這個是如何做到的，與它是typescript寫的有關係么？好想學習這門黑科技，大神賜教一下.

code 打開大文件只比 atom 快，100MB 以上或者超長行文件請找專用編輯器

因為顯示第一頁是很快的，完全可以後面偷偷的花很長時間大開大文件，然後先刷新出來給你看。這就是完全一樣的蘋果騙人說自己性能高的伎倆啊。

當然大部分程序員是不願意這麼做的，因為太麻煩（逃

如果文件只有幾百kb，全部load進內存。

如果文件有100G，全部load進內存可以阻擋99%的機器。

怎麼辦呢？如果以前沒有看過，那讀最開始100KB（拍腦袋的數字，具體還要看什麼page size，sector之類的），等你快滾到沒看過的那一部分，再偷偷摸摸地讀100KB。

如果有歷史瀏覽記錄，可以從最後瀏覽的位置開始，讀入100KB。但這種做法有個明顯的缺陷，就是不能從一開始就給你展現「當前是第幾行」。

只要處理好文件指針位置、有沒有EOF、保存的時候的處理（文件大小變了）、讀取上下區塊的時機、釋放的時機就可以了。難是不難，但做細緻了不容易。

另外一個更為現實的問題是，作為一個代碼編輯器，如果你的讀入引擎是block by block的，你讓各種插件怎麼配合？插件一定會把這種方法改成一次性全部讀進來……尤其是靜態分析和代碼提示類的插件。

但話又說回來，作為代碼編輯器，為什麼需要處理「大文件」？？？？我認為算是偽需求。

偷懶有理！！！

99.99999%一個字，MapViewOfFile。剩下的太複雜就不討論了。

沒遇到過這個？

這個文件只是普通的 postfix 的 log ，用 ccze 著色之後用 aha 轉成了標準的 html 方便人看的。真的沒有二進制數據也沒有特殊文字編碼。~~~~~~~~~~~~~~~~~~~~

補充：這個文件最長的行是 3130 字元（根據 wc -L），一般的編輯器比如 vim 和 subl3 開著代碼著色也能勝任。

以前做安卓軟體，TextView 載入超過 30 KB 的文本就感覺卡頓了。後來寫了一個類，用文件流 seek 的辦法，通過換行符作為界定，每次只讀取適當的長度，應該 vs 也是這種邏輯。但 Notepad++ 使用的演算法可能更合理，那個東東才是真的大文件秒開。

並不能秒開吧，打開大文件的時候也會讀條的。

而且有時候讀個幾十M的文件就說文件太大不顯示了。

類似的東西我差不多是做過的，實際上這並不是什麼黑科技，無非是解決界面上的邏輯，讓使用者不感到卡就好了，那麼多線程的優勢就出來了，界面層代碼上可以自己開一個線程去處理非同步邏輯，所有的界面庫例如GTK，QT，wxwidgets好像都有現成的idle函數來給使用者調用的，不知道輪子哥的GacUI有沒有，召喚輪子哥 @vczh

@馮子浩描述的很有意思，其實是不管文件大小,界面層都會去讀取一個固定大小的內容的（比如固定頁，固定內存），然後draw（）的時候再算出來當前顯示器的大小的內容，小文件感覺不出來，大文件內核層面還得去處理這個文件怎麼拆分，所以大文件會感覺略卡下，因為得算。

既然你很感興趣，既然typescript是JavaScript的一個超集，不如去看看這個開源的用JavaScript來解析pdf的項目，裡邊有相應的處理邏輯，這個項目我在本地改過，不過沒有提交哈哈哈。

鏈接：GitHub - mozilla/pdf.js: PDF Reader in JavaScript

這都能扯到typescript？

大文件秒開？多大在你那裡叫大？

醒醒吧，幾十個M就說打不開了，害得我還得開個VS……

除了從磁碟載入文件的優化，其它就是預載入了，就像chrome會猜測用戶可能會打開哪些網頁，提前在後台載入。

看到問題我趕緊試了試，根本不行。我一個700M的log告訴我打不開

我表示notepad打開1G文件沒問題

感覺跟無限循環滾動的banner有點像，用個圓形數據結構應該就行。

是進步不少，原先開sqlite源碼，幾十秒就崩了，現在不崩了。但是語法支持沒了。。。

才81M大小的文件都打不開,還說大文件秒開?

你這提問先入為主的給了一個肯定的話:"vscode編輯器打開大項目能夠快速預覽",不會是在做推廣吧?

這個不是webkit的特性？