Better performance when exploring big files

[Masterxilo]

No matter the size of the file, if it is clearly a binary file, the warning "The file is not displayed in the editor because it is binary" should be shown almost instantly. Currently, the time for this message to show up seems to depend on the size of the file and the editor hangs while this is being determined, making accidental clicks costly (timewise).

I sometimes work with multi-100 MB text fies and want to see what they look like by clicking on them instead of having to run head. I would expect clicking on a large text file to have no worse performance than opening a file with just a few dozen lines. Unfortunately, vscode hangs for quite a while before it determines it cannot load the file into memory and then applies the strategy of just displaying a few lines without formatting.
Instead, whenever opening a file, the first few lines should be shown almost instantly in every case.

Because of the current slowness of clicking on a large file, exploring just the first few lines of a bunch of huge text files is very costly (timewise).

Interestingly, vscode doesn't hang up completely when you click on a large text file, but when you click on a small one, it will not charge until the big one is ready. It seems there is only one queue for loading the files, so there's definitely some parallelization potential.

[bpasero]

No matter the size of the file, if it is clearly a binary file, the warning "The file is not displayed in the editor because it is binary" should be shown almost instantly. Currently, the time for this message to show up seems to depend on the size of the file and the editor hangs while this is being determined, making accidental clicks costly (timewise).

No, we try to detect if a file is binary reading the first 8kb or so.

[bpasero]

I think this needs a combination of editor support to stream a model while you scroll and support this in the file layer to only read what you see. We already support reading at position and offset, but it might not be exposed to extension authors.

//cc @hediet @alexdima

[VSCodeTriageBot]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[AlbertoPdRF]

Hey @bpasero!

I believe you are right when you say that reading at position and offset is not yet exposed to extension authors, see #84515 (comment). The proposed API, linked in the comment, is now on its own file here. Is there any plan to make this proposed API available to extension authors?

Thanks!

[VSCodeTriageBot]

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[VSCodeTriageBot]

🙁 In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.

Happy Coding!