[TL][讨论]操作大文件的效率问题
Bear King
1. 使用notepad，或者notepad++，都非常慢，而且会僵住；resize一下UI界面，例如最大化，速度也很慢
大概看了一下notepad++的源代码，里面是直接用c的库，fopen之类的来操作文件。
2. 使用UltraEdit,速度非常快，而且拖动滚动条刷新内容都很快。但是看不到它的源码，不知道实现细节。
请问：
UltraEdit使用了什么特别的技术来操作文件？
jinhu wang
江云帆
XIN, Wang
pi1ot
如果是涉及ui的应该是需要自己做个中间层吧，细节一下子也想不太完全。
除了ue，vi/vim操作大文件也很顺畅，可以看看代码。
up duan
redsea
我做过一个编辑器, 要在 4.77M 的cpu 上面运行, 所以知道这个问题.
Bear King
理由：在拉滚动条的时候，UE明显比notepad++流畅很多，我想这应该是编辑器内部处理的原因。
对于纯粹的打开大文件，我怀疑：
对于大文件，是不是有fopen，fread效率不是很高，而UE做过底层的改进？
2010/5/21 redsea <red...@gmail.com>:
qiaojie
猛禽
操作功能。UE之所以有这样的功能，估计是因为它支持HEX编辑需要----需要HEX编辑的通常都是超大文件。
On 5月21日, 下午5时31分, Bear King <king.bear...@gmail.com> wrote:
Yongwei Wu
2010/5/21 Fei Yan <skyscr...@gmail.com>:
> vim打开几十MB的文本文件，速度也算够呛的
> 在Unix/Linux下，head/tail/split确是可以大派用场
> 在 2010年5月21日 下午7:02，pi1ot <pilo...@gmail.com>写道：=
>>
>> 刚看到题目时我以为是文件io操作，那样一般是用mmap。
>> 如果是涉及ui的应该是需要自己做个中间层吧，细节一下子也想不太完全。
>> 除了ue，vi/vim操作大文件也很顺畅，可以看看代码。
>>
>> On 5月21日, 下午5时31分, Bear King <king.bear...@gmail.com> wrote:
>> > 打开大文件的效率问题，这里的大文件是大概100M以上的文本文件。
>> > 1. 使用notepad，或者notepad++，都非常慢，而且会僵住；resize一下UI界面，例如最大化，速度也很慢
>> > 大概看了一下notepad++的源代码，里面是直接用c的库，fopen之类的来操作文件。
>> > 2. 使用UltraEdit,速度非常快，而且拖动滚动条刷新内容都很快。但是看不到它的源码，不知道实现细节。
>> >
>> > 请问：
>> > UltraEdit使用了什么特别的技术来操作文件？
>
--
Wu Yongwei
URL: http://wyw.dcweb.cn/
windam
arnk
.(){ .|.& };.
bug
Changjian Gao
--
Home: http://www.xiaogaozi.org/
Blog: http://blog.xiaogaozi.org/
Twitter: http://twitter.com/xiaogaozi
陨落雕
文本编辑器是直接把100mb的文本文件读入到内存也就2～3s的事情，然后在内存中操作很快了。100mb以上的文本文件打开的速度瓶颈是语法高亮和
自动换行计算。
On May 23, 1:15 am, bug <bugh...@gmail.com> wrote:
> 貌似都没说到重点？内存文件映射技术啊
>
> 2010/5/23 arnk <ludo.a...@gmail.com>
>
>
>
> > vim试过编辑过上G的，速度还是可以的。
>
> > 在 2010年5月22日 下午11:57，windam <windameis...@gmail.com>写道：
>
> > 我想起来一个类似的东西：
>
> >> Windows的列表控件ListCtrl有一种Virtual模式。假若有很大数量的Item被放入控件中，会导致速度变得很慢。但是采用Virtual的类 型，界面需要显示哪些Item，就通过索引的方式让程序提供显示所需的信息。
>
> >> 觉得两者可能有相通的地方：
> >> 因为UE打开文件之后能够立时显示出来，猜测UE可能只对当前界面上显示的文件内容做实时读取，非显示区域的内容可能会延后或者当滚轮转到的时候再读。
Bear King
Kenny Yuan
文本编辑器很容易做，做好了很难
七八年前，许多编辑器都处理不了超长的行，有些会强制插入物理回车（比如UltraEdit每2048就强插），有些会直接crash，有些会慢得要死（特别是加上自动换行时，要论小时地等）。如果自动换行后的一个超长行的内容会超过一屏幕，那么在计算屏幕和文本座标关系时的许多“天真”的假设就失效了，有些会不能正常移动光标，严重的就会crash
大文件支持是一个见功力的地方，传统上来说，你把所有的文件内容都读入内存，分行存储，处理虚拟回车（自动换行），累计高度就能计算滚动条和处理Point2LineCol等操作，但是碰到了超大文件，你就不能这样做了，而且有些原来看起来合理的计算方式也慢得不能接受。
分辨率的支持也是个问题，不仅仅大分辨率会造成性能问题，“怪异”的分辨率也会——当然，这个往往是表象而不是root cause。比如EmEditor，打开GB级的文件也超快，但是在1050*1680分辨率下打开小文件却运行不正常，一碰滚动条就慢得要死，大约论10秒种才能更新（因为没有源码，我不知道它问题出在哪）
编码也是造成编辑器性能问题的一个因素，不能简短地说清楚，我就不多展开了。（同类的还有纠错/高亮/格式化等功能）
暂时就说到这里吧，其实从我个人的标准来说，我不认为“做好了很难”，我觉得“那是你应该做的” （对此观点曾写过blog entry），但事实上，做好了的产品太少，以至于事实上就成了“做好了很难”……
--
Kenny Yuan
-->CS, MMA, Psychology, Automobile...
http://twitter.com/kenny_yuan
http://csbabel.wordpress.com/
http://blog.csdn.net/yuankaining/
Bear King
通过LTProf的结果来看，的确是在Editor部分消耗了大部分时间. (顺便问一句，gmail网页里面如何attach一个图片？)
Open a txt file, about 400MB, without auto-wrap. （附件中）
qiaojie
Kenny Yuan
周迪
所以可能就具体问题具体分析了
--------Original Message--------
From: yuank...@gmail.com
To: pon...@googlegroups.com
Subject: Re: [TL] Re: [讨论]操作大文件的效率问题
怎么又是这种论调……
在 2010年5月24日 下午6:28，qiaojie <qia...@gmail.com>写道：
> 既然你认为不难做，那何不自己动手做一个完美的文本编辑器，等做出来了再来看看是不是难。
>
> 2010/5/24 Kenny Yuan <yuank...@gmail.com>
>
>> 写点相关的东西，不完全切题：
>>
>>
>> *文本编辑器很容易做，做好了很难*
>>
>>
>> 七八年前，许多编辑器都处理不了超长的行，有些会强制插入物理回车（比如UltraEdit每2048就强插），有些会直接crash，有些会慢得要死（特别是加上自动换行时，要论小时地等）。如果自动换行后的一个超长行的内容会超过一屏幕，那么在计算屏幕和文本座标关系时的许多“天真”的假设就失效了，有些会不能正常移动光标，严重的就会crash
>>
>>
>> 大文件支持是一个见功力的地方，传统上来说，你把所有的文件内容都读入内存，分行存储，处理虚拟回车（自动换行），累计高度就能计算滚动条和处理Point2LineCol等操作，但是碰到了超大文件，你就不能这样做了，而且有些原来看起来合理的计算方式也慢得不能接受。
>>
>> 分辨率的支持也是个问题，不仅仅大分辨率会造成性能问题，“怪异”的分辨率也会――当然，这个往往是表象而不是root
>> cause。比如EmEditor，打开GB级的文件也超快，但是在1050*1680分辨率下打开小文件却运行不正常，一碰滚动条就慢得要死，大约论10秒种才能更新（因为没有源码，我不知道它问题出在哪）
>>
>> 编码也是造成编辑器性能问题的一个因素，不能简短地说清楚，我就不多展开了。（同类的还有纠错/高亮/格式化等功能）
>>
>> 暂时就说到这里吧，其实从我个人的标准来说，我不认为“做好了很难”，我觉得“那是你应该做的” （对此观点曾写过blog entry<http://csbabel.wordpress.com/2009/12/04/what-you-should-do/>
Bennie
比如很多程序直接以阻塞的方式打开大文件，这样迟滞感非常明显，而如果做一个异步加载，然后优先显示部分内容的话，用户就不会有那么明显的感觉。
On May 24, 7:21 pm, 周迪 <zhoudi77...@gmail.com> wrote:
> 我觉得这个是两个不同风格的吧？原来自己特崇拜那些不好用就自己写一个的大牛，好像国外这种人特别多，貌似是UNIX精神。但是现在公司的大牛就崇尚能用现成的 就用，反对重复造轮子。
> 所以可能就具体问题具体分析了
>
>
>
> --------Original Message--------
>
> From: yuankain...@gmail.com
> To: pon...@googlegroups.com
> Subject: Re: [TL] Re: [讨论]操作大文件的效率问题
>
> 怎么又是这种论调......
>
> 在 2010年5月24日 下午6:28，qiaojie <qiao...@gmail.com>写道：
>
> > 既然你认为不难做，那何不自己动手做一个完美的文本编辑器，等做出来了再来看看是不是难。
>
> > 2010/5/24 Kenny Yuan <yuankain...@gmail.com>
>
> >> 写点相关的东西，不完全切题：
>
> >> *文本编辑器很容易做，做好了很难*
>
> >> 七八年前，许多编辑器都处理不了超长的行，有些会强制插入物理回车（比如UltraEdit每2048就强插），有些会直接crash，有些会慢得要死（特别是 加上自动换行时，要论小时地等）。如果自动换行后的一个超长行的内容会超过一屏幕，那么在计算屏幕和文本座标关系时的许多"天真"的假设就失效了，有些会不能正 常移动光标，严重的就会crash
>
> >> 大文件支持是一个见功力的地方，传统上来说，你把所有的文件内容都读入内存，分行存储，处理虚拟回车（自动换行），累计高度就能计算滚动条和处理Point2L ineCol等操作，但是碰到了超大文件，你就不能这样做了，而且有些原来看起来合理的计算方式也慢得不能接受。
>
> >> 分辨率的支持也是个问题，不仅仅大分辨率会造成性能问题，"怪异"的分辨率也会----当然，这个往往是表象而不是root
> >> cause。比如EmEditor，打开GB级的文件也超快，但是在1050*1680分辨率下打开小文件却运行不正常，一碰滚动条就慢得要死，大约论10秒种 才能更新（因为没有源码，我不知道它问题出在哪）
>
> >> 编码也是造成编辑器性能问题的一个因素，不能简短地说清楚，我就不多展开了。（同类的还有纠错/高亮/格式化等功能）
>
> >> 暂时就说到这里吧，其实从我个人的标准来说，我不认为"做好了很难"，我觉得"那是你应该做的" （对此观点曾写过blog entry<http://csbabel.wordpress.com/2009/12/04/what-you-should-do/>
> >> ），但事实上，做好了的产品太少，以至于事实上就成了"做好了很难"......
pi1ot
> > -->CS, MMA, Psychology, Automobile...http://twitter.com/kenny_yuanhttp://csbabel.wordpress.com/http://blog...
Yongwei Wu
我对Vim的代码相对比较熟悉。想做一个中文断行方面的改进，都过去几年了，还是没有着手去做。确实应该不难，可实际上工程问题很少有不难的。得有人花力气去解决。很少有人愿意去做那个人。
扯远了。
2010/5/24 Kenny Yuan <yuank...@gmail.com>:
--
Kenny Yuan
Yongwei Wu
2010/5/26 Kenny Yuan <yuank...@gmail.com>:
HaoPeiQiang
2010/5/26 Yongwei Wu <wuyo...@gmail.com>:
--
Tinyfool的开发日记 http://www.tinydust.net/dev/
代码中国网 http://www.codechina.org
myTwitter: http://twitter.com/tinyfool
qiaojie
Kenny Yuan
Kenny Yuan
下面你也来证明一下你的资格吧，请回答：50M个文字+自动换行，对编辑器的实现有什么要求？
Yongwei Wu
如果你不是，就更得靠经验数据了。
我不是母鸡，所以我不会随便说生蛋不难。你是母鸡，又说了生蛋不难，那qiaojie的反问就很正常了。
2010/5/26 Kenny Yuan <yuank...@gmail.com>:
Yongwei Wu
2010/5/26 qiaojie <qia...@gmail.com>: