&&&&Linux获取CPU 内存信息到文件C++简单实现
Linux获取CPU 内存信息到文件C++简单实现
在Linux系统下将cpu、内存等信息获取并放在同一个文件中的C++源码，需要g++才能编译
若举报审核通过，可奖励20下载分
被举报人：
feiya_is_here
举报的资源分：
请选择类型
资源无法下载
资源无法使用
标题与实际内容不符
含有危害国家安全内容
含有反动色情等内容
含广告内容
版权问题，侵犯个人或公司的版权
*详细原因：
VIP下载&&免积分60元/年（1200次）
您可能还需要
开发技术下载排行君，已阅读到文档的结尾了呢~~
莫托曼机器人的使用说明书
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
安川机器人使用说明书
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口Linux（78）
Linux文件预读算法磁盘I/O性能的发展远远滞后于CPU和内存，因而成为现代计算机系统的一个主要瓶颈。预读可以有效的减少磁盘的寻道次数和应用程序的I/O等待时间，是改进磁盘读I/O性能的重要优化手段之一。本文作者是中国科学技术大学自动化系的博士生，他在1998年开始学习Linux，为了优化服务器的性能，他开始尝试改进Linux kernel，并最终重写了内核的文件预读部分，这些改进被收录到Linux Kernel 2.6.23及其后续版本中。
从寄存器、L1/L2高速缓存、内存、闪存，到磁盘/光盘/磁带/存储网络，计算机的各级存储器硬件组成了一个金字塔结构。越是底层存储容量越大。然而访问速度也越慢，具体表现为更小的带宽和更大的延迟。因而这很自然的便成为一个金字塔形的逐层缓存结构。由此产生了三类基本的缓存管理和优化问题：
◆预取(prefetching)算法，从慢速存储中加载数据到缓存;
◆替换(replacement)算法，从缓存中丢弃无用数据;
◆写回(writeback)算法，把脏数据从缓存中保存到慢速存储。
其中的预取算法，在磁盘这一层次尤为重要。磁盘的机械臂+旋转盘片的数据定位与读取方式，决定了它最突出的性能特点:擅长顺序读写，不善于随机I/O，I/O延迟非常大。由此而产生了两个方面的预读需求。
来自磁盘的需求
简单的说，磁盘的一个典型I/O操作由两个阶段组成：
1.数据定位
平均定位时间主要由两部分组成：平均寻道时间和平均转动延迟。寻道时间的典型值是4.6ms。转动延迟则取决于磁盘的转速：普通7200RPM桌面硬盘的转动延迟是4.2ms，而高端10000RPM的是3ms。这些数字多年来一直徘徊不前，大概今后也无法有大的改善了。在下文中，我们不妨使用8ms作为典型定位时间。
2.数据传输
持续传输率主要取决于盘片的转速（线速度）和存储密度，最新的典型值为80MB/s。虽然磁盘转速难以提高，但是存储密度却在逐年改善。巨磁阻、垂直磁记录等一系列新技术的采用，不但大大提高了磁盘容量，也同时带来了更高的持续传输率。
显然，I/O的粒度越大，传输时间在总时间中的比重就会越大，因而磁盘利用率和吞吐量就会越大。简单的估算结果如表1所示。如果进行大量4KB的随机I/O，那么磁盘在99%以上的时间内都在忙着定位，单个磁盘的吞吐量不到500KB/s。但是当I/O大小达到1MB的时候，吞吐量可接近50MB/s。由此可见，采用更大的I/O粒度，可以把磁盘的利用效率和吞吐量提高整整100倍。因而必须尽一切可能避免小尺寸I/O，这正是预读算法所要做的。
表1& &随机读大小与磁盘性能的关系
来自程序的需求
应用程序处理数据的一个典型流程是这样的:while(!done) { read(); compute(); }。假设这个循环要重复5次，总共处理5批数据，则程序运行的时序图可能如图1所示。
图1 典型的I/O时序图
不难看出，磁盘和CPU是在交替忙碌：当进行磁盘I/O的时候，CPU在等待；当CPU在计算和处理数据时，磁盘是空闲的。那么是不是可以让两者流水线作业，以便加快程序的执行速度？预读可以帮助达成这一目标。基本的方法是，当CPU开始处理第1批数据的时候，由内核的预读机制预加载下一批数据。这时候的预读是在后台异步进行的，如图2所示。
图2 预读的流水线作业
注意，在这里我们并没有改变应用程序的行为：程序的下一个读请求仍然是在处理完当前的数据之后才发出的。只是这时候的被请求的数据可能已经在内核缓存中了，无须等待，直接就能复制过来用。在这里，异步预读的功能是对上层应用程序“隐藏”磁盘I/O的大延迟。虽然延迟事实上仍然存在，但是应用程序看不到了，因而运行的更流畅。
预读的概念
预取算法的涵义和应用非常广泛。它存在于CPU、硬盘、内核、应用程序以及网络的各个层次。预取有两种方案：启发性的(heuristic prefetching)和知情的(informed prefetching)。前者自动自发的进行预读决策，对上层应用是透明的，但是对算法的要求较高，存在命中率的问题；后者则简单的提供API接口，而由上层程序给予明确的预读指示。在磁盘这个层次，Linux为我们提供了三个API接口：posix_fadvise(2), readahead(2), madvise(2)。
不过真正使用上述预读API的应用程序并不多见：因为一般情况下，内核中的启发式算法工作的很好。预读(readahead)算法预测即将访问的页面，并提前把它们批量的读入缓存。
它的主要功能和任务可以用三个关键词来概括：
◆批量，也就是把小I/O聚集为大I/O，以改善磁盘的利用率，提升系统的吞吐量。
◆提前，也就是对应用程序隐藏磁盘的I/O延迟，以加快程序运行。
◆预测，这是预读算法的核心任务。前两个功能的达成都有赖于准确的预测能力。当前包括Linux、FreeBSD和Solaris等主流操作系统都遵循了一个简单有效的原则：把读模式分为随机读和顺序读两大类，并只对顺序读进行预读。这一原则相对保守，但是可以保证很高的预读命中率，同时有效率/覆盖率也很好。因为顺序读是最简单而普遍的，而随机读在内核来说也确实是难以预测的。
Linux的预读架构
Linux内核的一大特色就是支持最多的文件系统，并拥有一个虚拟文件系统(VFS)层。早在2002年，也就是2.5内核的开发过程中，Andrew Morton在VFS层引入了文件预读的基本框架，以统一支持各个文件系统。如图所示，Linux内核会将它最近访问过的文件页面缓存在内存中一段时间，这个文件缓存被称为pagecache。如图3所示。一般的read()操作发生在应用程序提供的缓冲区与pagecache之间。而预读算法则负责填充这个pagecache。应用程序的读缓存一般都比较小，比如文件拷贝命令cp的读写粒度就是4KB；内核的预读算法则会以它认为更合适的大小进行预读I/O，比比如16-128KB。
图3 以pagecache为中心的读和预读
大约一年之后，Linus Torvalds把mmap缺页I/O的预取算法单独列出，从而形成了read-around/read-ahead两个独立算法（图4）。read-around算法适用于那些以mmap方式访问的程序代码和数据，它们具有很强的局域性(locality of reference)特征。当有缺页事件发生时，它以当前页面为中心，往前往后预取共计128KB页面。而readahead算法主要针对read()系统调用，它们一般都具有很好的顺序特性。但是随机和非典型的读取模式也大量存在，因而readahead算法必须具有很好的智能和适应性。
图4 Linux中的read-around, read-ahead和direct read
又过了一年，通过Steven Pratt、Ram Pai等人的大量工作，readahead算法进一步完善。其中最重要的一点是实现了对随机读的完好支持。随机读在数据库应用中处于非常突出的地位。在此之前，预读算法以离散的读页面位置作为输入，一个多页面的随机读会触发“顺序预读”。这导致了预读I/O数的增加和命中率的下降。改进后的算法通过监控所有完整的read()调用，同时得到读请求的页面偏移量和数量，因而能够更好的区分顺序读和随机读。
预读算法概要
这一节以linux 2.6.22为例，来剖析预读算法的几个要点。
1.顺序性检测
为了保证预读命中率，Linux只对顺序读(sequential read)进行预读。内核通过验证如下两个条件来判定一个read()是否顺序读：
◆这是文件被打开后的第一次读，并且读的是文件首部；
◆当前的读请求与前一（记录的）读请求在文件内的位置是连续的。
如果不满足上述顺序性条件，就判定为随机读。任何一个随机读都将终止当前的顺序序列，从而终止预读行为（而不是缩减预读大小）。注意这里的空间顺序性说的是文件内的偏移量，而不是指物理磁盘扇区的连续性。在这里Linux作了一种简化，它行之有效的基本前提是文件在磁盘上是基本连续存储的，没有严重的碎片化。
2.流水线预读
当程序在处理一批数据时，我们希望内核能在后台把下一批数据事先准备好，以便CPU和硬盘能流水线作业。Linux用两个预读窗口来跟踪当前顺序流的预读状态：current窗口和ahead窗口。其中的ahead窗口便是为流水线准备的：当应用程序工作在current窗口时，内核可能正在ahead窗口进行异步预读；一旦程序进入当前的ahead窗口，内核就会立即往前推进两个窗口，并在新的ahead窗口中启动预读I/O。
3.预读的大小
当确定了要进行顺序预读(sequential readahead)时，就需要决定合适的预读大小。预读粒度太小的话，达不到应有的性能提升效果；预读太多，又有可能载入太多程序不需要的页面，造成资源浪费。为此，Linux采用了一个快速的窗口扩张过程：
◆首次预读： readahead_size = read_size * 2; // or *4
预读窗口的初始值是读大小的二到四倍。这意味着在您的程序中使用较大的读粒度（比如32KB）可以稍稍提升I/O效率。
◆后续预读： readahead_size *= 2;
后续的预读窗口将逐次倍增，直到达到系统设定的最大预读大小，其缺省值是128KB。这个缺省值已经沿用至少五年了，在当前更快的硬盘和大容量内存面前，显得太过保守。比如西部数据公司近年推出的WD Raptor 猛禽 10000RPM SATA 硬盘，在进行128KB随机读的时候，只能达到16%的磁盘利用率（图5）。所以如果您运行着Linux服务器或者桌面系统，不妨试着用如下命令把最大预读值提升到1MB看看，或许会有惊喜：
# blockdev –setra 2048 /dev/sda
当然预读大小不是越大越好，在很多情况下，也需要同时考虑I/O延迟问题。
图5 128KB I/O的数据定位时间和传输时间比重
重新发现顺序读
上一节我们解决了是否／何时进行预读，以及读多少的基本问题。由于现实的复杂性，上述算法并不总能奏效，即使是对于顺序读的情况。例如最近发现的重试读(retried read)的问题。
重试读在异步I/O和非阻塞I/O中比较常见。它们允许内核中断一个读请求。这样一来，程序提交的后续读请求看起来会与前面被中断的读请求相重叠。如图6所示。
图6 重试读(retried reads)
Linux 2.6.22无法理解这种情况，于是把它误判为随机读。这里的问题在于“读请求”并不代表读取操作实实在在的发生了。预读的决策依据应为后者而非前者。最新的2.6.23对此作了改进。新的算法以当前读取的页面状态为主要决策依据，并为此新增了一个页面标志位：PG_readahead，它是“请作异步预读”的一个提示。在每次进行新预读时，算法都会选择其中的一个新页面并标记之。预读规则相应的改为：
◆当读到缺失页面(missing page)，进行同步预读；
◆当读到预读页面(PG_readahead page)，进行异步预读。
这样一来，ahead预读窗口就不需要了：它实际上是把预读大小和提前量两者作了不必要的绑定。新的标记机制允许我们灵活而精确地控制预读的提前量，这有助于将来引入对笔记本省电模式的支持。
图7 Linux 2.6.23预读算法的工作动态
另一个越来越突出的问题来自于交织读(interleaved read)。这一读模式常见于多媒体／多线程应用。当在一个打开的文件中同时进行多个流(stream)的读取时，它们的读取请求会相互交织在一起，在内核看来好像是很多的随机读。更严重的是，目前的内核只能在一个打开的文件描述符中跟踪一个流的预读状态。因而即使内核对两个流进行预读，它们会相互覆盖和破坏对方的预读状态信息。对此，我们将在即将发布的2.6.24中作一定改进，利用页面和pagecache所提供的状态信息来支持多个流的交织读。
相关链接：
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：264734次
积分：4713
积分：4713
排名：第4253名
原创：209篇
转载：55篇
评论：19条
(1)(1)(1)(1)(1)(2)(1)(1)(1)(1)(1)(2)(1)(2)(2)(1)(5)(3)(1)(1)(2)(2)(2)(7)(2)(8)(5)(1)(1)(4)(2)(1)(1)(3)(2)(1)(1)(2)(3)(1)(3)(5)(1)(3)(6)(1)(4)(6)(7)(7)(14)(2)(2)(4)(4)(3)(14)(60)(7)(5)(3)(7)(10)(3)(3)(1)用C语言读取大文件的问题
用C语言读取大文件的问题
-我的论坛-
主 题：
用C语言读取大文件的问题
作 者：
等 级：
信 誉 值：
所属论坛：
问题点数：
回复次数：
发表时间：
最近打算用C写个程序，处理数据。每个数据文件1.6个G，文件集总大小在90G。小弟以前没有编过读取这种大程序的程序，没有什么思路，请各位高人知道一下，谢谢了先。
) 信誉：100
<font color="#07-7-2 3:07:58
得分:<font color="#
强,顶一个.我前不久也在问这个问题,有的说是用内存映射,不过不懂.
) 信誉：100
<font color="#07-7-2 8:15:34
得分:<font color="#
内存映射不行,一个文件都有1.6G了,用户内存空间地址一共才3G,要是出现文件合并情况,那不就over了,不过可以分段映射,就是会很麻烦的.这就要看你要怎么处理你的数据了.
) 信誉：100
<font color="#07-7-2 8:22:37
得分:<font color="#
文件你又不需要一下都读出来，文件内容有没有格式？分段读取吧
) 信誉：100
<font color="#07-7-2 8:38:22
得分:<font color="#
【Ref】Windows对文件的读写提供了很丰富的操作手段，如:1. FILE *fp, fstearm...; (C/C++)2. CFile, CStdioFile...; (MFC)3. CreateFile, ReadFile...;(API)...在处理一般的文件(文本/非文本),这些足够了。然而在处理比较大的文件如几十M, 几百M, 甚至上G的文件, 这时再用一般手段处理，系统就显的力不从心了要把文件读出，再写进，耗费的是CPU利用率与内存以及IO的频繁操作。这显然是令用户难以忍受的为了解决这个吃内存，占CPU，以及IO瓶颈，windows核心编程提供了内存映射文件技术(Maping File)至于Maping File是什么原理，我不多说了，网上转载资源一箩筐，我只想从应用层来考虑，怎样用这个技术，实现日常项目中的应用举例来说:可能项目中，会经常用到一些大量的常量，而这些大量常量用宏来替代写再源文件中显然不可取，一般是写在文件中，给常量一些编号，通过编号来索引一般文件比较小时候，常用做法也是先预读到内存中，毕竟从内存中读比从文件中读要快(IO操作的瓶颈)比较好的做法，读到STL MAP 中去:例如一个索引文件:SEU=汪洋中的一片叶子JIANGSHENG=蒋晟SEU=CSDN............打开文件，解析=号，在解析方面有CString操作,strtok,strstr, boost 正则表达式匹配等等，但我比较喜欢sscanf(szIndex, "%[^=]=%[^=]", sName, sValue);sscanf(szIndex, "%[^=]=%s", sName, sValue);fscanf(stream, "%[^=]=%[^=]", sName, sValue);之类,然后再定义一个map:map&string, string& m_Mm_Map[sName] = sV但是文件比较大的时候，笔者做过测试，用上面方法处理一个15M, 25万行的文本文件，占用内存非常的高，达70多M,处理的速度也非常的慢，这还不包括回写到文件这时，Maping File就派上用场了，这里处理大文件就抛弃了map的应用(因为容器占用很多内存)而是直接利用字符指针来操作，不用其他封装，不多说了，请看示例: #pragma warning(disable: 4786) #include &windows.h&#include &stdio.h&#include &iostream&#include &string&string GetValue(const TCHAR *, const TCHAR *);
//根据name得valuevoid main(int argc, char* argv[]){
// 创建文件对象(C: est.tsr)
HANDLE hFile = CreateFile("C:\test.tsr", GENERIC_READ | GENERIC_WRITE,
0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
if (hFile == INVALID_HANDLE_VALUE)
printf("创建文件对象失败,错误代码:%d ", GetLastError());
// 创建文件映射对象
HANDLE hFileMap = CreateFileMapping(hFile, NULL, PAGE_READWRITE, 0, 0, NULL);
if (hFileMap == NULL)
printf("创建文件映射对象失败,错误代码:%d ", GetLastError());
// 得到系统分配粒度
SYSTEM_INFO SysI
GetSystemInfo(&SysInfo);
DWORD dwGran = SysInfo.dwAllocationG
// 得到文件尺寸
DWORD dwFileSizeH
__int64 qwFileSize = GetFileSize(hFile, &dwFileSizeHigh);
qwFileSize |= (((__int64)dwFileSizeHigh) && 32);
// 关闭文件对象
CloseHandle(hFile);
// 偏移地址
__int64 qwFileOffset = 0;
DWORD dwBlockBytes = 1000 * dwG
if (qwFileSize & 1000 * dwGran)
dwBlockBytes = (DWORD)qwFileS
if (qwFileOffset &= 0)
// 映射视图
TCHAR *lpbMapAddress = (TCHAR *)MapViewOfFile(hFileMap,FILE_MAP_ALL_ACCESS,
dwBlockBytes);
if (lpbMapAddress == NULL)
printf("映射文件映射失败,错误代码:%d ", GetLastError());
//-----------------------访问数据开始-------------------------
cout&&GetValue(lpbMapAddress,"SEU")&&
getchar();//-----------------------访问数据结束-------------------------
// 撤销文件映像
UnmapViewOfFile(lpbMapAddress);
// 关闭文件映射对象句柄
CloseHandle(hFileMap);
}string GetValue(const TCHAR *lpbMapAddress, const TCHAR *sName){
// 存放 = 后面的value值
TCHAR *p1 = NULL, *p2 = NULL; // 字符指针
if((p1 = strstr(lpbMapAddress,sName)) != NULL) // 查找sName出现位置
if(p2 = strstr(p1,"\r\n")) *p2 = ‘\0‘; // 查找"\r\n"(换行)出现位置
sValue = p1+strlen(sName)+strlen("="); // 指针移动"sName"+"="之后
*p2 = ‘\r‘;
// 还原*p2值,因为不还原会改变原文件结构
return sV}... 以上实现了根据索引name匹配value的简单过程，经测试，同样25W行文件，匹配耗费1秒不到，且不占本进程内存。以上修改lpbMapAddress任意处值，也不需要重新回写到文件，真正是大大提高了文件读与写的效率该文章转载自网络大本营：/Info/13520.Html
) 信誉：100
<font color="#07-7-2 8:42:08
得分:<font color="#
用映射的方式时,不在于你读不读进来,它是要把文件的地址空间和进程的地址空间对应起来,1.6G的文件占用的进程地址空间是1.6G.只要映射了,不管读不读,它都占用了这段空间.当然你分段映射是没问题地.
) 信誉：100
<font color="#07-7-2 8:47:22
得分:<font color="#
using mmap
) 信誉：101
<font color="#07-7-2 9:01:32
得分:<font color="#
http://www./read.php/1252.htm
) 信誉：100
<font color="#07-7-2 9:45:39
得分:<font color="#
) 信誉：100
<font color="#07-7-2 9:58:24
得分:<font color="#
内存映射不行,一个文件都有1.6G了,用户内存空间地址一共才3G,要是出现文件合并情况,那不就over了,不过可以分段映射,就是会很麻烦的.这就要看你要怎么处理你的数据了.========================================================================================可以地，映射了，处理多少提交多少的即可
) 信誉：100
<font color="#07-7-2 10:44:13
得分:<font color="#
读写文件容易，pc server上一分钟可以fgets 5-10G； 主要是你的数据处理是什么逻辑；线性，多项式，指数时间复杂度？？ 这些没搞清楚，累死你。。。fopen64---fgets/fputsread/write
) 信誉：100
<font color="#07-7-2 10:57:13
得分:<font color="#
内存映射不行,一个文件都有1.6G了,用户内存空间地址一共才3G,要是出现文件合并情况,那不就over了,不过可以分段映射,就是会很麻烦的.这就要看你要怎么处理你的数据了.========================================================================================可以地，映射了，处理多少提交多少的即可--------------------------------这要看具体他的处理逻辑,频繁的调用mmap(),munmap(),效率很成问题.
) 信誉：100
<font color="#07-7-2 12:12:56
得分:<font color="#
内存映射不行,一个文件都有1.6G了,用户内存空间地址一共才3G,要是出现文件合并情况,那不就over了,不过可以分段映射,就是会很麻烦的.这就要看你要怎么处理你的数据了.========================================================================================可以地，映射了，处理多少提交多少的即可--------------------------------这要看具体他的处理逻辑,频繁的调用mmap(),munmap(),效率很成问题.＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝这个说法是对的，呵呵^_^，okokok
) 信誉：100
<font color="#07-7-2 14:14:07
得分:<font color="#
? 内存映射不行,一个文件都有1.6G了,用户内存空间地址一共才3G,要是出现文件合并情况,那不就over了,不过可以分段映射,就是会很麻烦的.这就要看你要怎么处理你的数据了.========================================================================================可以地，映射了，处理多少提交多少的即可--------------------------------这要看具体他的处理逻辑,频繁的调用mmap(),munmap(),效率很成问题.＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝这个说法是对的，呵呵^_^，okokok-------------------------------------高手风范,我有点偏执了.^_^^_^
) 信誉：100
<font color="#07-7-2 14:23:52
得分:<font color="#
呵呵，看了上面的帖子还不是太明白，我再慢慢理解先。我
处理的数据是普通ASCII码的，具体说是星表，每一行对应一颗星体，包含光度，坐标等几十个信息，都是整数或字符串，有具体的数据格式解释文件，总共
20亿个星体需要检索。初步的设想是分段读入，比如一次读进500行再查找、排序。内存映射没有接触过，所以也不知道是什么原理，我再上网找找。不知各位
还有什么好的建议没有？
) 信誉：100
<font color="#07-7-2 15:53:00
得分:<font color="#
mmap 只是在頻繁需要隨機訪問一個文件的位置的時候才有很大的優勢如果不是這種情況mmap效率的確很抵
) 信誉：100
<font color="#07-7-2 22:25:11
得分:<font color="#
) 信誉：100
<font color="#07-7-2 22:27:59
得分:<font color="#
) 信誉：100
<font color="#07-7-2 23:34:26
得分:<font color="#
MARK是什么东东呢？我是菜鸟，没有用过啊
) 信誉：100
<font color="#07-7-3
得分:<font color="#
) 信誉：100
<font color="#07-7-3 0:39:06
得分:<font color="#
那我的每次读500行的计划可不可行啦？
) 信誉：100
<font color="#07-7-3 0:54:07
得分:<font color="#
MARK下，想知道……
) 信誉：100
<font color="#07-7-3 7:00:31
得分:<font color="#
) 信誉：100
<font color="#07-7-3 10:35:45
得分:<font color="#
) 信誉：100
<font color="#07-7-3 12:15:57
得分:<font color="#
就当普通文件处理，完全可以一次处理若干行，分次处理，内存映射只是效率比较高，和文件大小没有关系
) 信誉：100
<font color="#07-7-3 12:19:36
得分:<font color="#
) 信誉：100
<font color="#07-7-3 12:34:48
得分:<font color="#
) 信誉：100
<font color="#07-7-3 12:37:20
得分:<font color="#
建议楼主把问题描述清楚，毕竟你要解决的是个具体问题。
) 信誉：100
<font color="#07-7-3 12:37:59
得分:<font color="#
) 信誉：100
<font color="#07-7-3 12:48:36
得分:<font color="#
) 信誉：100
<font color="#07-7-3 13:23:37
得分:<font color="#
看了楼上的贴一下子感觉明白的很多,这个问题楼主问的很好,正好也是我们这些新手不懂的东西有没有朋友推荐介绍相关知识的书籍
) 信誉：100
<font color="#07-7-3 14:00:05
得分:<font color="#
) 信誉：100
<font color="#07-7-3 14:00:26
得分:<font color="#
如果有这方面的书籍推荐就更好了
) 信誉：100
<font color="#07-7-3 14:30:44
得分:<font color="#
) 信誉：100
<font color="#07-7-3 14:57:51
得分:<font color="#
) 信誉：100
<font color="#07-7-3 14:58:31
得分:<font color="#
回复人：bartonhong() ( 一级(初级)) 信誉：100
14:00:26 得分:0? 如果有这方面的书籍推荐就更好了**********************************************windows核心编程里有例子，详细地讲述了如何高效读取大文件
) 信誉：100
<font color="#07-7-3 14:59:15
得分:<font color="#
) 信誉：100
<font color="#07-7-3 15:12:58
得分:<font color="#
《windows高级编程》讲得很详细
) 信誉：100
<font color="#07-7-3 15:39:25
得分:<font color="#
学习学习 ………………
) 信誉：100
<font color="#07-7-3 15:47:57
得分:<font color="#
我就不明白了，文件里有数据，那就一点一点的老老实实的读吧，写吧，文件不是有Seek功能吗（假如你的介质支持随机访问）？那就要哪儿读哪儿呗。不明白楼主为什么要问，或许是源于一些特殊的读写需求？？反正你是没法一次性读进内存的。那就要哪里就seek到哪里去读写。事先根据你的文件数据存储格式，以及可能用到的查询逻辑，设计好一个完备无误的文件内字节位置计算程序，这很重要，然后就定位＋读写啦。不明白楼上的一个个都说什么呢？！“在处理一般的文件(文本/非文本),这些足够了。然而在处理比较大的文件如几十M, 几百M, 甚至上G的文件, 这时再用一般手段处理，系统就显的力不从心了”。这是什么狗屁理论？谁教你的？还什么内存映射吧云云。再说楼主压根也没有说是在Windows平台啊，映个什么射啊？还有人连“STL MAP”都给扯进来了……
) 信誉：100
<font color="#07-7-3 16:23:34
得分:<font color="#
呵呵，大家都是在耐心帮我的。我觉得顺序分段读取是可行的，但咱这不是追求更高效的解决方法嘛，所以来问下高手们的建议。毕竟90G的文件用笔记本检索效率还是很重要的，我没有高性能的机器……上面提到的书已经下载了，慢慢研习中
) 信誉：100
<font color="#07-7-3 16:38:42
得分:<font color="#
) 信誉：100
<font color="#07-7-3 16:40:57
得分:<font color="#
楼上们的, 对于处理这么大的文件, 系统是不是会处理很长时间, 然后占用的资源也很多, 比如很长时间内都将cpu占用到100%? 如果这样, 那系统里其他的还在运行的东东怎么办, 特别是系统资源比较紧张的时候.
) 信誉：100
<font color="#07-7-3 16:46:48
得分:<font color="#
磁盘映射到内存的技术。。。。
) 信誉：100
<font color="#07-7-3 16:52:51
得分:<font color="#
我就不明白了，文件里有数据，那就一点一点的老老实实的读吧，写吧，文件不是有Seek功能吗（假如你的介质支持随机访问）？那就要哪儿读哪儿呗。不明白楼主为什么要问，或许是源于一些特殊的读写需求？？反正你是没法一次性读进内存的。那就要哪里就seek到哪里去读写。事先根据你的文件数据存储格式，以及可能用到的查询逻辑，设计好一个完备无误的文件内字节位置计算程序，这很重要，然后就定位＋读写啦。不明白楼上的一个个都说什么呢？！“在处理一般的文件(文本/非文本),这些足够了。然而在处理比较大的文件如几十M, 几百M, 甚至上G的文件, 这时再用一般手段处理，系统就显的力不从心了”。这是什么狗屁理论？谁教你的？还什么内存映射吧云云。再说楼主压根也没有说是在Windows平台啊，映个什么射啊？还有人连“STL MAP”都给扯进来了……－－－－－－－－－－－－－－－－－－－－－－《windows高级编程》“内存映射”讲了一例子，看完之后你就知道内存映射的好处了。当然，如果不是windows平台的话就另当别论了。
) 信誉：100
<font color="#07-7-3 17:14:11
得分:<font color="#
老老实实的读吧，用内存映射能快不少
) 信誉：100
<font color="#07-7-3 17:16:44
得分:<font color="#
我就不明白了，文件里有数据，那就一点一点的老老实实的读吧，写吧，文件不是有Seek功能吗（假如你的介质支持随机访问）？那就要哪儿读哪儿呗。不明白楼主为什么要问，或许是源于一些特殊的读写需求？？反正你是没法一次性读进内存的。那就要哪里就seek到哪里去读写。事先根据你的文件数据存储格式，以及可能用到的查询逻辑，设计好一个完备无误的文件内字节位置计算程序，这很重要，然后就定位＋读写啦。不明白楼上的一个个都说什么呢？！“在处理一般的文件(文本/非文本),这些足够了。然而在处理比较大的文件如几十M, 几百M, 甚至上G的文件, 这时再用一般手段处理，系统就显的力不从心了”。这是什么狗屁理论？谁教你的？还什么内存映射吧云云。再说楼主压根也没有说是在Windows平台啊，映个什么射啊？还有人连“STL MAP”都给扯进来了……－－－－－－－－－－－－－－－－－－－－－－《windows高级编程》“内存映射”讲了一例子，看完之后你就知道内存映射的好处了。当然，如果不是windows平台的话就另当别论了。----------------------------------------unix下一样的,对于文件内容的随机操作,mmap的效率比fseek高这是很显然的.
) 信誉：100
<font color="#07-7-3 17:26:53
得分:<font color="#
关注，以后程序水平高点后也来一下
) 信誉：100
<font color="#07-07-03 22:16:16
得分:<font color="#
) 信誉：100
<font color="#07-07-03 23:56:14
得分:<font color="#
像楼主所说的问题，对于大文件的操作，我们应当用到内存映射机制即可
) 信誉：100
<font color="#07-07-04 00:03:49
得分:<font color="#
但如果是linix下,也是用内存映射机制吗?还是内存映射机制是windows特有的.
百联美达美公司 版权所有 京ICP证020026号
Copyright ? CSDN.net, Inc. All rights reserved
发表评论：
TA的最新馆藏[转]&[转]&[转]&[转]&
