sublimetext 2 真的是用c++写的吗，处理一个160k的css反应迟缓

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

This topic created in 4582 days ago, the information mentioned may be changed or developed.

ctrl+f搜索url标签都能卡一会
更别说我想要用ctrl+h把每个class都弄成一行了。
直接用虚拟机里的editplus搞定了，虽然功能不咋样但是效率靠谱。

ubuntu 12.04.3 + 4G + i3

ctrl

虚拟机

URL

26 replies • 1970-01-01 08:00:00 +08:00

rrfeng

Nov 4, 2013

sublimetext 不是用 python 写的吗？

未发现楼主所说问题，话说我本来想用 st3 打开 2000w 的 csv 来着
结果读取一大半的时候崩溃了 XD

NemoAlex

Nov 4, 2013

天天处理200多k的 CSS 无压力
我用的也是 Mac 版

letitbesqzr

Nov 4, 2013

@rrfeng 哈哈。2000W csv 是kaifang数据? ... 经常要打开几百M的文本... sublimetext 都是加载一会就死了... win7 自带的写字板加载非常流畅..

Jat001

Nov 4, 2013

滚动页面卡吗？试试在设置中加入 "scroll_speed": 0,

ivenvd

Nov 4, 2013

不清楚 ST2，但是在 Vim 下这种情况多半是语法高亮导致的。那么大的文件还要高亮，用什么编辑器都够受吧……

zzNucker

Nov 4, 2013

python写的啦。。。。

hooluupog

Nov 4, 2013

扩展插件部分是用python写的，其他的肯定不是。

rqrq

Nov 4, 2013

@ivenvd editplus性能很高啊
才160k而已，如果很卡只能说内部算法有问题。

learnshare

Nov 4, 2013

ST2 的批量替换卡的有模有样

westup

Nov 4, 2013

用3吧，快很多

Sherlockhlt

Nov 4, 2013

@rqrq
同意，与语言无关，是算法问题

stackpop

Nov 4, 2013

100M以上文件，我一般都用Nodepad++

yakczh

Nov 4, 2013

试试emeditor

est

Nov 4, 2013

Sublime是C++基于OpenGL写的。插件体系用python

其次，LZ的问题估计有很多中文。。我这里也是一样的bug

rqrq

Nov 4, 2013

@est css文件，没有中文的。。

octopus_new

Nov 4, 2013

@est 感觉甚是混乱, "C++基于 OpenGL 写的", 斗胆问一下, 这个出处在哪里么. 凭对 OpenGL 的了解, OpenGL 直接渲染文字比较不直接, 这得多大毅力用 OpenGL 写文字编辑器啊......

jianghu52

Nov 5, 2013

我开大文件都是用emeditor，感觉还可以。主要是他好像可以一部分读取。

dancercl

Nov 5, 2013

Sublime Text插件都是Python写的，所以插件装的太多，或者某些插件有bug，可能会显著降低速度

est

Nov 5, 2013

@octopus_new https://www.sublimetext.com/forum/viewtopic.php?f=2&t=2000

黑科技。。Chrome也是用的OpenGL。微软也搞了个Direct2D

octopus_new

Nov 5, 2013

@est 长见识了......
不过 Chrome 用 OpenGL 写我倒是可以理解, 毕竟除了文字之外还有很多其他的东西要渲染, 纯文本编辑器用 OpenGL 写也真是挺牛x了.
PS:对微软的东西有点不太了解, 之前只是在琢磨 OpenGL 的时候看了一下 D3D 的东西, 现在 MS 又弄个 D2D, 我记得好像微软废了 DirectDraw 是负责2D 的, 难道被重写赋予新的使命了......, 感觉无比蛋痛.

tcsky

Nov 5, 2013

常见的几个编辑器好像都是基于Scintilla组件~ 都没法编辑大文件那个什么什么 emeditor 可以,而且很流畅

ivenvd

Nov 7, 2013

@rqrq 你觉得 Vim 会在语法高亮算法上有问题？正常的源文件都不会那么长吧？160KB 已经可以存中长篇小说了……

rqrq

Nov 7, 2013

@ivenvd
为什么vim就不可以有算法问题啊？
很多人已经提到了windows下面几款软件处理大文件是ok的。
你认为vim没问题，那就是说打开的方式不对？

noark9

Nov 8, 2013

太大的文件，一般定位都很难吧，用文本编辑器打开来顺着编辑。。。很崩溃的感觉。。。配合下grep，awk，sed感觉应该更合适处理这些问题吧

ivenvd

Nov 11, 2013

@rqrq 很好，你成功把我的几个问题都曲解掉了。

我说的是“Vim 语法高亮算法不会有问题”，就被你曲解为“Vim 不会有算法问题”。

我说“源文件通常不会那么长”，你回避掉。

前面几位老兄虽然提到 Windows 下处理文件 OK，却没有提语法高亮的问题，而我的观点一直没有离开语法高亮，不知道你拿这些反驳我有什么意义。

我只能说，如果有编辑器能够流畅处理大文件同时开启语法高亮，那肯定也是刻意优化过这种情况，并且高亮是不完整的。而不是 Vim 高亮算法有问题。

rqrq

Nov 11, 2013

@ivenvd

quote:我说的是“Vim 语法高亮算法不会有问题”，就被你曲解为“Vim 不会有算法问题”。
我在8楼回复你，原意是编辑器的内部算法有问题。
少写了4个字，以至于让你理解为语法高亮的内部算法。
后面产生的这些口水，是因为我在8楼没说清楚，是我的错。
但是我还是想问：
为什么vim就不可以在语法高亮算法上有问题啊？

quote:我说“源文件通常不会那么长”，你回避掉。
我发这个帖子就在说源文件很长带来的性能问题，你跟我说通常不会那么长。
我说这个你说那个。

quote:“前面几位老兄虽然提到 Windows 下处理文件 OK，却没有提语法高亮的问题……”
抬杠之前麻烦你仔细看帖，我在楼顶就说了，虚拟机下的editplus处理这个css文件是ok的。
我想我不用再啰嗦这么一句吧：editplus打开代码格式的文件是有语法高亮的。

quote:“并且高亮是不完整的”
我不得不再问下你：不~完~整~是~怎~么~样~的~不~完~整~啊？