删除文件我只知道读取到内存中,然后重写,但对1G这样的大文件,这样操作效率就太低了
各位有啥好方法没,100分送上
40 个解决方案
#1
可以试试文件内存映射。。。。
#2
内存文件映射
`
`
#3
这种需求应该是没有什么好方法的。
#4
删除大文件,也可以先把这部分数据抹掉,不用真正的删除
如果有索引的话,也可以把索引置为无效状态
这样的话,速度就会比较的话,但会浪费磁盘空间
如果有索引的话,也可以把索引置为无效状态
这样的话,速度就会比较的话,但会浪费磁盘空间
#5
看数据库是怎么做的
reply too short
reply too short
#6
这个用流文件觉的没有很好的方法;
我在vim下编辑大的文件的时候都处理的不是很好;
应该考虑下记录文件的形式;但是在一个文本编辑器中使用像数据库那样的形式处理感觉有点浪费
看你具体的应用
我在vim下编辑大的文件的时候都处理的不是很好;
应该考虑下记录文件的形式;但是在一个文本编辑器中使用像数据库那样的形式处理感觉有点浪费
看你具体的应用
#7
内存映射+1
#8
mmap() 映射到内存,操作完后unmap()
也可以使用同步跟新
也可以使用同步跟新
#9
文件映射......
#10
内存映射。。。。。。。。
#11
内存映射吧,没其他太好的了
#12
内存映射具体怎么操作啊
#13
内存映射
mmap() 映射到内存,操作完后unmap()
mmap() 映射到内存,操作完后unmap()
#14
对于超大文本来说,修改表+合并应该是性能最高的解决方案.
#15
windows的话,MapViewOfFile函数和CreateFileMapping,OpenFileMapping函数,这三个函数用来进行内存映射。可以搜一下用法。
linux是mmap。
linux是mmap。
#16
CreateFileMapping
MapViewOfFile
内存读写
UnmapViewOfFile
CloseHandle
#17
学习了 U.............P
#18
内存映射应该可以,你试一下
#19
又长见识了,以前还真不知道文件可以这样操作,谢谢各位了!
#20
学习了。。。。。。。
#21
将大文件拆成1M大小的小文件,今后修改只对小文件修改即可。我没研究过文件系统,不过问我的同事,据他了解,没有发现可以从中间修改文件内容的方法。(我以前用一个日志文件记录设备上发生的问题,后来发现随着文件的不断扩大,读写都容易出现问题,结果改成日志文件超过1M就启动新的日志文件,这样读写就比较稳定,修改也比较容易)
#22
学习了!!!!!!!!!!!!!!!!
#23
读写超过1G的大文件,怎么都快不了多少(当然,部分读写除外);
所以,建议拆解大文件,每个小文件最多几十兆(或更小),那么就快多了;
而且,内存映射也不是万能的,一个进程的可映射内存空间是相当有限的,尤其是加载DLL较多的时候;我们就经常遇到,映射超过250MByte以上的空间频繁失败的情况,更不用说映射高达1G的内存文件了,基本上100%失败(想象一下要找到一个大小为1G的连续空间,在一个加载众多DLL的进程中,那是多么困难),最后改成64MByte映射才没有失败的情况出现了。
所以,建议拆解大文件,每个小文件最多几十兆(或更小),那么就快多了;
而且,内存映射也不是万能的,一个进程的可映射内存空间是相当有限的,尤其是加载DLL较多的时候;我们就经常遇到,映射超过250MByte以上的空间频繁失败的情况,更不用说映射高达1G的内存文件了,基本上100%失败(想象一下要找到一个大小为1G的连续空间,在一个加载众多DLL的进程中,那是多么困难),最后改成64MByte映射才没有失败的情况出现了。
#24
也可以考虑把TXT文件的内容导入到数据库中,然后操作数据库。
#25
learning。。。
#26
改成ISAM文件吧。
#27
内存映射 .............
#28
这个不错
#29
只能用数据库作为工作时临时文件。
0 启动程序时读取并分析文本文件,生成中间数据库,主要是按一定策略将文本文件分块(例如每512字节1块或每个标点处1块或碰到回车换行就算1块)并建立索引,以便快速定位什么内容在磁盘上什么位置。这个过程1G的文件耗时2-5秒。
1 写的话就按块写到数据库中并进行索引。
2 读的时候先通过索引判断该文本是否在数据库中,以便决定从数据库中或源文件中读取。
3 关闭程序时整合数据库和源文件内容生成一个新文本文件。这个过程1G的文件耗时3-10秒。
4 删除源文件和中间数据库。
5 备注:数据块写到数据库中,但块索引需要用链表保存,使得插入和删除块特别方便。
0 启动程序时读取并分析文本文件,生成中间数据库,主要是按一定策略将文本文件分块(例如每512字节1块或每个标点处1块或碰到回车换行就算1块)并建立索引,以便快速定位什么内容在磁盘上什么位置。这个过程1G的文件耗时2-5秒。
1 写的话就按块写到数据库中并进行索引。
2 读的时候先通过索引判断该文本是否在数据库中,以便决定从数据库中或源文件中读取。
3 关闭程序时整合数据库和源文件内容生成一个新文本文件。这个过程1G的文件耗时3-10秒。
4 删除源文件和中间数据库。
5 备注:数据块写到数据库中,但块索引需要用链表保存,使得插入和删除块特别方便。
#30
这个确实是个问题啊,学习中。。。。
#31
MARK !!!!!!!!!!!!!!!!!
#32
貌似这个方法不错,C语言里怎么对数据库操作啊
#33
1G的txt前所未有= = 开眼了。
#34
有数据库效率会高一些
#35
mark!
回复内容太短了!
回复内容太短了!
#36
把1~20的全排列保存到txt里
绝对有1G
#37
纯c语言可用的数据库多了,简单的有 B-Tree,商业级有 C-Tree,免费的有 MySQL ………… 当然要安装数据库然后用人家的开发接口来做。
更简单的话,不用现成的数据库,就按照教科书上给出的 B-Tree 原理自己实现一个简易的伪数据库也费不了多少事。
#38
可用的数据库很多,可以用oracle数据库!再利用pro*c(c语言中嵌套sql语句)来对数据库进行操作!
#39
内存 分割,然后截取读取
#40
1G的txt记事本能打开么。。。?
学习了。。。。。。。。
学习了。。。。。。。。
#1
可以试试文件内存映射。。。。
#2
内存文件映射
`
`
#3
这种需求应该是没有什么好方法的。
#4
删除大文件,也可以先把这部分数据抹掉,不用真正的删除
如果有索引的话,也可以把索引置为无效状态
这样的话,速度就会比较的话,但会浪费磁盘空间
如果有索引的话,也可以把索引置为无效状态
这样的话,速度就会比较的话,但会浪费磁盘空间
#5
看数据库是怎么做的
reply too short
reply too short
#6
这个用流文件觉的没有很好的方法;
我在vim下编辑大的文件的时候都处理的不是很好;
应该考虑下记录文件的形式;但是在一个文本编辑器中使用像数据库那样的形式处理感觉有点浪费
看你具体的应用
我在vim下编辑大的文件的时候都处理的不是很好;
应该考虑下记录文件的形式;但是在一个文本编辑器中使用像数据库那样的形式处理感觉有点浪费
看你具体的应用
#7
内存映射+1
#8
mmap() 映射到内存,操作完后unmap()
也可以使用同步跟新
也可以使用同步跟新
#9
文件映射......
#10
内存映射。。。。。。。。
#11
内存映射吧,没其他太好的了
#12
内存映射具体怎么操作啊
#13
内存映射
mmap() 映射到内存,操作完后unmap()
mmap() 映射到内存,操作完后unmap()
#14
对于超大文本来说,修改表+合并应该是性能最高的解决方案.
#15
windows的话,MapViewOfFile函数和CreateFileMapping,OpenFileMapping函数,这三个函数用来进行内存映射。可以搜一下用法。
linux是mmap。
linux是mmap。
#16
CreateFileMapping
MapViewOfFile
内存读写
UnmapViewOfFile
CloseHandle
#17
学习了 U.............P
#18
内存映射应该可以,你试一下
#19
又长见识了,以前还真不知道文件可以这样操作,谢谢各位了!
#20
学习了。。。。。。。
#21
将大文件拆成1M大小的小文件,今后修改只对小文件修改即可。我没研究过文件系统,不过问我的同事,据他了解,没有发现可以从中间修改文件内容的方法。(我以前用一个日志文件记录设备上发生的问题,后来发现随着文件的不断扩大,读写都容易出现问题,结果改成日志文件超过1M就启动新的日志文件,这样读写就比较稳定,修改也比较容易)
#22
学习了!!!!!!!!!!!!!!!!
#23
读写超过1G的大文件,怎么都快不了多少(当然,部分读写除外);
所以,建议拆解大文件,每个小文件最多几十兆(或更小),那么就快多了;
而且,内存映射也不是万能的,一个进程的可映射内存空间是相当有限的,尤其是加载DLL较多的时候;我们就经常遇到,映射超过250MByte以上的空间频繁失败的情况,更不用说映射高达1G的内存文件了,基本上100%失败(想象一下要找到一个大小为1G的连续空间,在一个加载众多DLL的进程中,那是多么困难),最后改成64MByte映射才没有失败的情况出现了。
所以,建议拆解大文件,每个小文件最多几十兆(或更小),那么就快多了;
而且,内存映射也不是万能的,一个进程的可映射内存空间是相当有限的,尤其是加载DLL较多的时候;我们就经常遇到,映射超过250MByte以上的空间频繁失败的情况,更不用说映射高达1G的内存文件了,基本上100%失败(想象一下要找到一个大小为1G的连续空间,在一个加载众多DLL的进程中,那是多么困难),最后改成64MByte映射才没有失败的情况出现了。
#24
也可以考虑把TXT文件的内容导入到数据库中,然后操作数据库。
#25
learning。。。
#26
改成ISAM文件吧。
#27
内存映射 .............
#28
这个不错
#29
只能用数据库作为工作时临时文件。
0 启动程序时读取并分析文本文件,生成中间数据库,主要是按一定策略将文本文件分块(例如每512字节1块或每个标点处1块或碰到回车换行就算1块)并建立索引,以便快速定位什么内容在磁盘上什么位置。这个过程1G的文件耗时2-5秒。
1 写的话就按块写到数据库中并进行索引。
2 读的时候先通过索引判断该文本是否在数据库中,以便决定从数据库中或源文件中读取。
3 关闭程序时整合数据库和源文件内容生成一个新文本文件。这个过程1G的文件耗时3-10秒。
4 删除源文件和中间数据库。
5 备注:数据块写到数据库中,但块索引需要用链表保存,使得插入和删除块特别方便。
0 启动程序时读取并分析文本文件,生成中间数据库,主要是按一定策略将文本文件分块(例如每512字节1块或每个标点处1块或碰到回车换行就算1块)并建立索引,以便快速定位什么内容在磁盘上什么位置。这个过程1G的文件耗时2-5秒。
1 写的话就按块写到数据库中并进行索引。
2 读的时候先通过索引判断该文本是否在数据库中,以便决定从数据库中或源文件中读取。
3 关闭程序时整合数据库和源文件内容生成一个新文本文件。这个过程1G的文件耗时3-10秒。
4 删除源文件和中间数据库。
5 备注:数据块写到数据库中,但块索引需要用链表保存,使得插入和删除块特别方便。
#30
这个确实是个问题啊,学习中。。。。
#31
MARK !!!!!!!!!!!!!!!!!
#32
貌似这个方法不错,C语言里怎么对数据库操作啊
#33
1G的txt前所未有= = 开眼了。
#34
有数据库效率会高一些
#35
mark!
回复内容太短了!
回复内容太短了!
#36
把1~20的全排列保存到txt里
绝对有1G
#37
纯c语言可用的数据库多了,简单的有 B-Tree,商业级有 C-Tree,免费的有 MySQL ………… 当然要安装数据库然后用人家的开发接口来做。
更简单的话,不用现成的数据库,就按照教科书上给出的 B-Tree 原理自己实现一个简易的伪数据库也费不了多少事。
#38
可用的数据库很多,可以用oracle数据库!再利用pro*c(c语言中嵌套sql语句)来对数据库进行操作!
#39
内存 分割,然后截取读取
#40
1G的txt记事本能打开么。。。?
学习了。。。。。。。。
学习了。。。。。。。。