请问大文件编辑为什么会明显变慢

[vyan13]

是因为实时渲染的缘故吗，如果是这样的话，或许可以只编辑不渲染，编辑完成再统一渲染

[hemashushu]

主要是因为文本编辑框的内容（文档原文本）是整体解析的，所以每改变一个字符都会让整个解析过程跑一遍，当时写 0.1 时没多想顺手就是写成这种结构。

到 0.7 或者 0.8 版时我会把它更改为基于行解析，这样编辑框在保持灵敏反应时可以容纳大概到 ~8MB 左右（目前大概只能编辑 ~64KB）。但这个改动牵涉面太大，一旦改起来接近把底层重写一遍，可能又要一年半载了，所以准备在基本功能都完成后再开始。

[bizchina]

自己挖坑自己埋，舒坦

[gregwym]

作者不考虑开源嘛？

[MetalGearBronya]

原来还有这个限制，我刚想说report一个bug。 Windows，最新版Yu Writer 具体复现方法是打开一个稍大的文件（我这个是183k，是复制的terminal里的历史，用其他editor检检查过没有非法字符），然后直接就卡死了（甚至会白屏）（18k的文件也会有明显卡顿）。 从任务栏关闭之后用任务管理器可以看到后台仍有两个Yu Writer的进程，如果不结束那两个进程直接重开，打开后点击任何之前那个session里打开过的文件都会蹦出一个文件读取的javascript error（Uncaught Exception: TypeError: Cannot read property 'WebContents' of null) （追溯到原因是read after open，即之前的file 没有close）。 结束了那两个进程中的任意一个（另一个会被一并带走）则会导致所有打开的tab丢失，但其他功能均恢复正常。

现在看来这是大文件处理的连带问题，不需要专门解决。 就我的use case来说，我是用Yu Writer整理md文件，所以基本不会预览全文，如果能用lazy-loading之类的方式保证打开文件的速度（大概只加载屏幕范围+半屏就够了），应该就非常好用了。 另外我这两个文件其实是txt，是不需要渲染的，Yu Writer好像做了归一化处理，把它也跟md按一个流程处理了，如果能在文件类型这里就作出区分，应该也能解决很多加载问题。 以上。

[hemashushu]

@MetalGearBronya 谢谢你的详细反馈和建议！下个版本会对这个问题改进。