较大数据文件的读取优化过程

最新推荐文章于 2024-06-26 15:22:13 发布
最新推荐文章于 2024-06-26 15:22:13 发布
阅读量7.2k 收藏 6
点赞数 3
分类专栏： MFC 杂项 文章标签： 优化 大文件 内存文件映射
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/sunnyloves/article/details/50510542
版权
MFC 同时被 2 个专栏收录
46 篇文章 1 订阅
订阅专栏
杂项
30 篇文章 4 订阅
订阅专栏

问题由来

1.解析一个体积较大（50MB，约50w行）的数据文件时，遇到了读取、解析花费的时间较长（debug下20+s，release下3s）速度较慢的问题。
2.用UE或者everedit等编辑软件打开这种文件基本上只要0.5s不到的时间。
因此尝试优化代码，提高效率，这里记录下过程。

测试平台

环境

win10x64 + VS2015

文件格式

数据文件分为三段：

第一段 230000 250000
第二段开始 1 115.853843 22.534526 -47.04851444
………….
第二段结束 230000 ………………………
第三段开始 1 3 2 96 1 0
………………………..
第三段结束 250000 ………………….

处理过程

基本方法

最基本的MFC读数据方式：CStdioFile打开文件-Readstring读取每行数据-查找分隔符-分割出字符串-转化为浮点数-保存到数组里去。

void CGRDFile::OpenStdioFile(CString sFileName)
{
    CStdioFile m_file; 
    m_file.Open(sFileName, CFile::modeRead);

    Vertex v;
    MeshIndex mesh;
    CString smn, sm, sn,sVertex, sN, sX, sY, sZ, sLeft, sMesh, s1Index, s2Index, s3Index;

    m_file.ReadString(smn);
    smn.Trim();

    sm = smn.Left(smn.Find(' '));
    sn = smn.Mid(smn.Find(' '), smn.GetLength() - 1);
    sn.Trim();

    m_grdFile.mn.m = _wtoi(sm);
    m_grdFile.mn.n = _wtoi(sn);
    //预分配数组大小
    m_grdFile.vVertex.reserve(m_grdFile.mn.m);
    m_grdFile.vMeshIndex.reserve(m_grdFile.mn.n);
    //第二段处理
    for (int i = 0; i < m_grdFile.mn.m; i++)
    {
        m_file.ReadString(sVertex);

        sVertex.Trim();
        sN = sVertex.Left(sVertex.Find(' '));
        sLeft = sVertex.Right(sVertex.GetLength() - sN.GetLength());
        sLeft.Trim();

        sX = sLeft.Left(sLeft.Find(' '));
        sLeft = sLeft.Right(sLeft.GetLength() - sX.GetLength());
        sLeft.Trim();

        sY = sLeft.Left(sLeft.Find(' '));
        sLeft = sLeft.Right(sLeft.GetLength() - sY.GetLength());
        sLeft.Trim();

        sZ = sLeft;

        v.nIndex = _wtoi(sN);
        v.x = _wtof(sX);
        v.y = _wtof(sY);
        v.z = _wtof(sZ);

        m_grdFile.vVertex.push_back(v);
        //第三段处理类似，不贴了
    }

经过测试上面的代码在release下读取完数据耗时2779.03ms在debug下耗时21122ms。

内存文件映射法

内存文件映射是一个提高大文件读取速度的方法。

void CGRDFile::OpenFile(CString sFileName)
{
    HANDLE hFile = CreateFile(
        sFileName,
        FILE_SHARE_READ ,
        0,
        0,
        OPEN_EXISTING,
        FILE_ATTRIBUTE_NORMAL,
        NULL);
    if (hFile == INVALID_HANDLE_VALUE)
    {

        return ;
    }
    HANDLE hFileMap = CreateFileMapping(hFile, NULL, PAGE_READONLY, 0, 0, NULL);
    if (hFileMap == NULL)
    {

        return;
    }
    // 得到系统分配粒度  
    SYSTEM_INFO SysInfo;
    GetSystemInfo(&SysInfo);
    DWORD dwGran = SysInfo.dwAllocationGranularity;

    // 得到文件尺寸  
    DWORD dwFileSizeHigh;
    __int64 qwFileSize = GetFileSize(hFile, &dwFileSizeHigh);
    qwFileSize |= (((__int64)dwFileSizeHigh) << 32);



    // 偏移地址   
    __int64 qwFileOffset = 0;

    // 块大小 
    DWORD dwBlockBytes = 0;
    for (int i = 1; ; ++i)
    {
        if (qwFileSize <= i * dwGran)
        {
            dwBlockBytes = i * dwGran;
            break;
        }
    }
    if (qwFileOffset >= 0)
    {
        // 映射视图
        //如果在调用MapViewOfFile()的时候，dwNumberOfBytesToMap如果大于文件的size，那么该call就会失败，
        //并且error code是access denied。所以MapViewOfFile的最后一个参数不能用dwBlockSize而只能用qwFileSize。
        //MapViewOfFile的返回值不能是TCHAR*，因为UNICODE时解释成宽字符，会出错，只能用char*
        char *lpbMapAddress = (char *)MapViewOfFile(hFileMap, FILE_MAP_READ, 0, 0, qwFileSize);
        if (lpbMapAddress == NULL)
        {           
            return;
        }
        CString stemp(lpbMapAddress);
        CString smn,sm, sn;

        smn = stemp.Left(stemp.Find('\n'));
        smn.Trim();
        sm = smn.Left(smn.Find(' '));
        sn = smn.Mid(smn.Find(' '), smn.GetLength() - 1);
        sn.Trim();

        m_grdFile.mn.m = _wtoi(sm);
        m_grdFile.mn.n = _wtoi(sn);
        //预分配数组大小
        m_grdFile.vVertex.reserve(m_grdFile.mn.m);
        m_grdFile.vMeshIndex.reserve(m_grdFile.mn.n);
        //顶点数组
        Vertex v;
        CString sVertex, sN, sX, sY, sZ, sLeft;

        int nStart, nEnd;
        nStart = stemp.Find('\n');
        nEnd = stemp.Find('\n', nStart + 1);
        for (int i = 0; i < m_grdFile.mn.m; i++)
        {
            sVertex = stemp.Mid(nStart+ 1, nEnd - nStart + 1);

            sVertex.Trim();
            sN = sVertex.Left(sVertex.Find(' '));
            sLeft = sVertex.Right(sVertex.GetLength() - sN.GetLength());
            sLeft.Trim();

            sX = sLeft.Left(sLeft.Find(' '));
            sLeft = sLeft.Right(sLeft.GetLength() - sX.GetLength());
            sLeft.Trim();

            sY = sLeft.Left(sLeft.Find(' '));
            sLeft = sLeft.Right(sLeft.GetLength() - sY.GetLength());
            sLeft.Trim();

            sZ = sLeft;

            v.nIndex = _wtoi(sN);
            v.x = _wtof(sX);
            v.y = _wtof(sY);
            v.z = _wtof(sZ);

            m_grdFile.vVertex.push_back(v);

            nStart = stemp.Find('\n', nEnd);
            nEnd = stemp.Find('\n', nStart + 1);
        }
        //网格数组
        CString sMesh, s1Index, s2Index, s3Index;
        MeshIndex mesh;
        for (int i = 0; i < m_grdFile.mn.n; i++)
        {
            sMesh = stemp.Mid(nStart + 1, nEnd - nStart + 1);

            sMesh.Trim();
            sN = sMesh.Left(sMesh.Find(' '));
            sLeft = sMesh.Right(sMesh.GetLength() - sN.GetLength());
            sLeft.Trim();

            s1Index = sLeft.Left(sLeft.Find(' '));
            sLeft = sLeft.Right(sLeft.GetLength() - s1Index.GetLength());
            sLeft.Trim();
            s1Index = sLeft.Left(sLeft.Find(' '));
            sLeft = sLeft.Right(sLeft.GetLength() - s1Index.GetLength());
            sLeft.Trim();

            s2Index = sLeft.Left(sLeft.Find(' '));
            sLeft = sLeft.Right(sLeft.GetLength() - s2Index.GetLength());
            sLeft.Trim();

            s3Index = sLeft.Left(sLeft.Find(' '));

            mesh.nIndex = _wtoi(sN);
            mesh.nV1Index = _wtoi(s1Index);
            mesh.nV2Index = _wtoi(s2Index);
            mesh.nV3Index = _wtoi(s3Index);

            m_grdFile.vMeshIndex.push_back(mesh);

            nStart = stemp.Find('\n', nEnd);
            nEnd = stemp.Find('\n', nStart + 1);
        }


        // 撤销文件映像
        UnmapViewOfFile(lpbMapAddress);
        // 关闭文件对象  
        CloseHandle(hFile);
    }



}

经过测试上面的代码在release下读取完数据耗时1437.46ms在debug下耗时13738ms。

再优化下

仔细观察了数据文件，每行占的字节数、每个值占得字节数其实是都是确定的，利用这个特点，可以避免循环里非常复杂耗时的字符串解析过程。

//内存文件映射部分代码不贴了，和上面一样
        Vertex v;
        MeshIndex mesh;
        CString smn, sm, sn, sVertex, sN, sX, sY, sZ, sLeft, sMesh, s1Index, s2Index, s3Index,sblank;
        smn = stemp.Left(MN_LINE_SIZE);
        smn.Trim();

        sm = smn.Mid(0, MN_M_CHAR_SIZE);
        sn = smn.Mid(MN_M_CHAR_SIZE, MN_N_CHAR_SIZE);

        m_grdFile.mn.m = _wtoi(sm);
        m_grdFile.mn.n = _wtoi(sn);
        //预分配数组大小
        m_grdFile.vVertex.reserve(m_grdFile.mn.m);
        m_grdFile.vMeshIndex.reserve(m_grdFile.mn.n);
        //顶点数组
        for (int i = 0; i < m_grdFile.mn.m; i++)
        {
            sVertex = stemp.Mid(MN_LINE_SIZE + i * VERTEX_LINE_SIZE, VERTEX_LINE_SIZE);
            sN = sVertex.Mid(0, VERTEX_N_CHAR_SIZE);
            sX = sVertex.Mid(VERTEX_N_CHAR_SIZE , VERTEX_X_CHAR_SIZE);
            sY = sVertex.Mid(VERTEX_N_CHAR_SIZE + VERTEX_X_CHAR_SIZE , VERTEX_Y_CHAR_SIZE);
            sZ = sVertex.Mid(VERTEX_N_CHAR_SIZE + VERTEX_X_CHAR_SIZE + VERTEX_Y_CHAR_SIZE, VERTEX_Z_CHAR_SIZE);

            v.nIndex = _wtoi(sN);
            v.x = _wtof(sX);
            v.y = _wtof(sY);
            v.z = _wtof(sZ);

            m_grdFile.vVertex.push_back(v);
        }
        //网格数组
        for (int i = 0; i < m_grdFile.mn.n; i++)
        {
            sMesh = stemp.Mid(MN_LINE_SIZE + m_grdFile.mn.m * VERTEX_LINE_SIZE + MESH_LINE_SIZE * i , 
                MESH_LINE_SIZE);
            sN = sMesh.Mid(0, MESH_N_CHAR_SIZE);
            s1Index = sMesh.Mid(MESH_N_CHAR_SIZE + MESH_NODEFINE_CHAR_SIZE , MESH_V1_CHAR_SIZE);
            s2Index = sMesh.Mid(MESH_N_CHAR_SIZE + MESH_NODEFINE_CHAR_SIZE + MESH_V1_CHAR_SIZE , MESH_V2_CHAR_SIZE);
            s3Index = sMesh.Mid(MESH_N_CHAR_SIZE + MESH_NODEFINE_CHAR_SIZE + MESH_V1_CHAR_SIZE + MESH_V2_CHAR_SIZE ,
                MESH_V3_CHAR_SIZE);

            mesh.nIndex = _wtoi(sN);
            mesh.nV1Index = _wtoi(s1Index);
            mesh.nV2Index = _wtoi(s2Index);
            mesh.nV3Index = _wtoi(s3Index);

            m_grdFile.vMeshIndex.push_back(mesh);

        }

经过测试上面的代码在release下读取完数据耗时642ms在debug下耗时4763ms。

性能比较

性能比较
从图上可以看到使用了内存文件映射后，读取性能有了较大提高，在release下解析的速度可以和UE之类的软件比较了。

洗洗睡去
关注
  • 3
    点赞
  • 踩
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
5.11 Go语言文本大数据处理（2）：文件分割与入库
欧阳桫的技术博客
02-19 2098
需求分析 上一节我们对文本大数据进行了读入和清洗，这一节我们把清洗后的数据存入MySQL数据库，清洗过后的有效信息约为1800万条； 思路分析 要想提高数据写入的速度，我们一方面要做并发的数据库写入，一方面又要尽量减少操作的次数，一次性插入尽可能多的记录； 最终的方案如下： 主要的性能瓶颈其实是主协程对文本的读取速度，可以事先对文件进行分割操作，然后并发地做数据读入； 主协程逐条读...
java读取文件效率优化_java 读文件 性能
weixin_32101377的博客
02-27 1446
虽然同为LSM-tree架构，X-Engine的设计哲学与传统基于LSM-tree架构的Rocksdb等引擎并不完全一致，如下图所示：设计关键点1：X-Engine磁盘上的数据，在常态下只有两层(L1/L2)，L0层是MemTable在compaction来不及的情况下暂存到磁盘上缓解内存压力时才启用的，正常情况下被冻结的MemTable可以直接和磁盘上的L1合并。设计关键点2：在L1/L2之间的...
超大文件读取性能最佳方案
qq_41737501的博客
05-11 432
超大文件读取
优化Java中文件读写的性能策略
最新发布
技术研究中心
06-26 389
大家好，我是免费搭建查券返利机器人省钱赚佣金就用微赚淘客系统3.0的小编，也是冬天不穿秋裤，天冷也要风度的程序猿！
如何优化大文件读取时的性能
DKPT的博客
05-29 429
1、如果你的应用是多线程的，并且文件可以被独立地划分为多个部分，那么可以使用多个线程或进程同时读取和处理文件的不同部分。1、不要一次性将整个文件加载到内存中，而是将其分割成多个较小的块（例如，每块1MB或更大），然后逐块读取和处理。1、使用性能监视工具（如JProfiler、VisualVM等）来监视你的应用的性能，并找出可能的瓶颈。2、确保你的系统有足够的RAM和适当的磁盘I/O带宽来支持大文件的读取。1、根据你的应用的需求，调整JVM的堆大小和其他相关参数。2、确保JVM有足够的内存来处理大文件。
关于Windows文件读写(提高读写速度)
l460602540的专栏
11-16 9422
这几天在研究怎么才能加快windows文件读写速度，搜了很多文章，MSDN也看了不少。稍微给大家分享一下。 限制windows文件读写速度的瓶颈其实最终还是来源于我们硬盘的固有特性，磁盘本身的转速和硬盘的串行化工作机制。我们所能做的只是改善软件实现方法去逼近硬盘的极限读写速度。平时我们在拷贝粘贴文件的时候，其实是用的windows本身的实现，其中有一个很大的影响速度的地方就是它们都用了win
java 内存文件 加速_Java 读取大文件有什么可以优化的吗
weixin_42299066的博客
02-24 407
展开全部优化一：采用内存硬盘(RamDisk)62616964757a686964616fe59b9ee7ad9431333363373732内存硬盘可以极大地提高文件的读写速度，行情的读写是应用内存硬盘的绝好情况：1，可以把行情小站的行情文件地址配置在内存硬盘上。这样可以加速行情小站写文件的速度。2，本系统再从内存硬盘读取，又可以加快读取速度。3，内存硬盘掉电后会丢失文件，这里基本不在乎这个缺点...
java poi 读取百万数据OOM优化
06-26
EasyExcel是阿里巴巴开源的一个轻量级Java库，专门针对大数据量的Excel读写进行了优化。EasyExcel通过事件驱动的模型，只在内存中保留当前处理的行数据，极大地降低了内存消耗。从描述来看，EasyExcel的读取速度比...
php笔记之：有规律大文件的读取与写入的分析
10-27
有规律的文件读取效率问题主要是因为 file() 函数将文件的每一行作为一个数组元素读取到内存中，这种操作对大文件来说消耗较大。推荐的替代方法是使用 file_get_contents() 函数配合 explode() 函数。file_get_...
STL文件的读取显示.zip_STL c++_STL文件_STL读取_读取stl_读取stl文件
09-21
ASCII格式的STL文件内容可读性较强，但文件大小较大；二进制格式则更紧凑，读写速度更快。每个STL文件包含一个头信息和一系列的三角形面片描述。头信息通常为“solid”开头，然后是一些描述性的文字，接着是三角形...
python读取大文件越来越慢的原因与解决
09-18
在使用Python读取大文件时，开发者可能会遇到一个普遍现象——随着文件读取的进行，处理速度越来越慢。这一问题的出现可能会导致程序运行效率低下，影响开发者的编程体验和程序性能。在本文中，我们将探讨造成Python...
Win32超大文件读写源码
12-30
Windows 32位平台下超大文件读写源码 读写4G以上(64位长度,即unsigned __int64)的文件 示例源码,免费下载和使用
java海量数据读写优化方案
09-06
对大数据文本文件读取（按行读取）的优化，目前常规的方案有三种，第一种LineNumberReader，第二种RandomAccessFile，第三种是内存映射文件在RandomAccessFile基础上调用getChannel().map(...)；代码提供在RandomAccessFile基础上，整合内部缓冲区，效率会有提高，测试过程中1000w行数据用时1秒，1亿行数据用时103（比1438秒快了13倍左右）
大文件读写优化问题。现有两个文件，一个837M的order.tbl，一个3.62G的lineitem.tbl，对这两个表进行嵌套连接
CHENYUNHE
12-30 1828
在做数据库作业时遇到的优化问题！ 作业要求： 实现一个基于嵌套循环策略的两表连接算法 • 算法原理： FOR EACH CHUNK c1 OF t1 { IF c1 NOT IN MEMORY READ CHUNK c1 INTO MEMORY FOR EACH ROW r1 IN CHUNK c1 { ...
如何优化Python读取大文件的内存占用与性能
qalangtao的博客-qalangtao.com
01-24 825
除了以上提到的优化方式以外，我们还可以使用第三方库来优化文件读取性能，比如使用pandas库中的read_csv函数来逐块读取大型CSV文件。内存映射文件是一种将文件映射到内存中的技术，可以在内存中直接操作文件，而不需要将整个文件加载到内存中。在这段优化后的代码中，我们使用了mmap.mmap函数将文件映射到内存中，并使用iter函数逐行读取文件。这样就可以在内存中直接操作文件，而不需要将整个文件加载到内存中。在优化后的代码中，我们使用了一个while循环来逐行读取文件，并在处理完每一行后立即释放内存。
较大数据文件的读取优化过程续
小猿一枚的专栏
04-12 1855
由来在上一篇博客（见参考1）中写了从基本到优化的过程，但仍然有可以优化的余地，这里记录下。问题文章1中根据固定行字节数优化读取速度有很大的弊端，就是需要解析的文件可能是不规则行长度的。可以有通用的按行解析的方法。当然前提仍然是基于内存映射文件。这里操作一个dat文件，共分n段，数据以空格分隔，行以\r\n分隔，大部分段平均每行大约10个双精度浮点数，小部分整数。共180w行，300MB大小。char
对大数据文本文件读取（按行读取）的优化
weixin_33948416的博客
03-16 664
2019独角兽企业重金招聘Python工程师标准>>> ...
利用多线程技术优化文件读写转换处理
The power of C, the secret of MD
05-22 3533
在电信系统CDR处理中，有大量的原始话单数据需要被读取、转换后再写入新的文件。如果使用C语言实现，一个复杂的读写转换处理过程可以分为以下几步： 从源文件中读取一块数据建立相应的数据结构并将读取的数据，以及定义源文件数据格式的配置文件，一并映射到该结构中，如果是线性的数据结构，例如NSN默认的CDR文件，一般采用单向链表，如果是非线性的数据结构，例如Ericsson默认的CDR文件，
RandomAccessFile读性能优化
qq_35939417的博客
10-19 1841
公司的日志采集器是我自己开发的，没用开源产品。日志采集虽然是个小功能，但是要想写好也没那么容易。对于一个日志采集器来说，它应该稳定、可控、占用尽量少的资源。因为日志采集器是和核心业务服务部署在同一台服务器上，如果它工作时CPU和内存占用率飙升、重度磁盘I/O，显然是不合适的，毕竟只是一个辅助功能，不能因小失大。在生产环境运行时发现部分服务日志过多，日志采集器的采集速度跟不上，日志上报有较大延迟。在对我自己编写的代码进行优化后，我想看看jdk的代码有没有优化的空间。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值