search

zed-industries / zed

Code at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
https://zed.dev
Other
46.78k stars 2.67k forks source link

Large file performance #4701

Open 0x2CA opened 1 year ago

0x2CA commented 1 year ago

Check for existing issues

Describe the bug / provide steps to reproduce it

Open a 4G file, it is stuck for a very long time, and the memory consumption is very high. Forced to quit the software, the program has been reduced from 28.9 GB of memory to 16.28 GB. The program is almost unusable.

Environment

Zed: v0.89.2 (stable) OS: macOS 13.4.0 Memory: 32 GiB Architecture: aarch64

If applicable, add mockups / screenshots to help explain present your vision of the feature

No response

If applicable, attach your ~/Library/Logs/Zed/Zed.log file to this issue.

If you only need the most recent lines, you can run the zed: open log command palette action to see the last 1000.

log.txt

mocenigo commented 5 months ago

For such a large file you should use some editor that does not keep the whole file in memory. And editing can be in all cases quite painful.

0x2CA commented 4 months ago

For such a large file you should use some editor that does not keep the whole file in memory. And editing can be in all cases quite painful.

Editing can be painful, but the possibility of opening up editing should not be discarded ,We can discard some useless functions to realize it, such as lsp,As far as I know the one that handles large files better is https://en.wikipedia.org/wiki/EmEditor

mocenigo commented 4 months ago

For such a large file you should use some editor that does not keep the whole file in memory. And editing can be in all cases quite painful.

Editing can be painful, but the possibility of opening up editing should not be discarded ,We can discard some useless functions to realize it, such as lsp,As far as I know the one that handles large files better is https://en.wikipedia.org/wiki/EmEditor

I would not define LSP useless. Of course some features can be disabled for large files, like LSP and tree-sitter.

The Internal structures of an editor are chosen on order to facilitate the use cases the editor is supposed to be applied to. I had myself some doubts about the particular use of ropes in Zed, but the work of @mrnugget after our interactions has shown that Zed can keep its performance while halving memory requirement asymptotically (I take no merits, I mostly complained…). This should bring the memory footprint to below SublimeText, even.

Editing huge files is a niche use case. While I myself test my editors with 138MB TeX files, which is unrealistic, to stress them, if I wanted to open a 4Gb file I would use an editor like Joe or Kate (Kate has a macOS port: it is based on GTK, the UI is not smooth, but, being based on scintilla, it should be able to do just that). Geany seems to be another option.

Timmmm commented 3 weeks ago

Editing huge files is a niche use case.

I'm not sure that's really true. I frequently find myself at least viewing and diffing very large log files. And in the past I have needed to open gigabyte level JSON files just like @0x2CA (hint btw: the best option I found in the end for viewing enormous JSON files, weirdly was Firefox).

It's quite jarring to have to switch entire editors just to view a big log file that your program generated when it's right there in your editor.

I think disabling features like syntax highlighting and collaborative editing - even editing entirely - would be acceptable. VSCode handles this surprisingly well... Do you really want to be shown up by a web-based editor? 😬