Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Large file handling using MFC

Large file handling using MFC

Scheduled Pinned Locked Moved C / C++ / MFC
c++cssalgorithmsjsonperformance
6 Posts 4 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • V Offline
    V Offline
    Vikas K
    wrote on last edited by
    #1

    Hi, I'm working on an application where it loads a huge file (like 4-6GB) and parses the file, searching for regular expressions, converting from Hex to Human readable form, filters etc. Since the file is of very large size, I'm facing lot of performance issues where it takes hours to process and show the file information in a window. To overcome this, what I did is, break the entire file into logical segments of 1 MB each and process 3 segments at a time. When the user is scrolling, the next segments will be processed. With this, a certain amount of improvements were done. But it is limited to files which are less than 300MB or so. For files which are over GBs, it is just crawling and pathetic. Wondering if there is any better way to handle these large files in a better way so that the user need not wait for hours? Will a buffered read and caching the decoded information in a temporary files using a thread would help? How can we make sure that the GUI doesn't hang during these intensive parsing process? Really appreciate your suggestions. Thanks Vikas

    V _ N S 4 Replies Last reply
    0
    • V Vikas K

      Hi, I'm working on an application where it loads a huge file (like 4-6GB) and parses the file, searching for regular expressions, converting from Hex to Human readable form, filters etc. Since the file is of very large size, I'm facing lot of performance issues where it takes hours to process and show the file information in a window. To overcome this, what I did is, break the entire file into logical segments of 1 MB each and process 3 segments at a time. When the user is scrolling, the next segments will be processed. With this, a certain amount of improvements were done. But it is limited to files which are less than 300MB or so. For files which are over GBs, it is just crawling and pathetic. Wondering if there is any better way to handle these large files in a better way so that the user need not wait for hours? Will a buffered read and caching the decoded information in a temporary files using a thread would help? How can we make sure that the GUI doesn't hang during these intensive parsing process? Really appreciate your suggestions. Thanks Vikas

      V Offline
      V Offline
      Vikas K
      wrote on last edited by
      #2

      by the way, the application is written in MFC

      1 Reply Last reply
      0
      • V Vikas K

        Hi, I'm working on an application where it loads a huge file (like 4-6GB) and parses the file, searching for regular expressions, converting from Hex to Human readable form, filters etc. Since the file is of very large size, I'm facing lot of performance issues where it takes hours to process and show the file information in a window. To overcome this, what I did is, break the entire file into logical segments of 1 MB each and process 3 segments at a time. When the user is scrolling, the next segments will be processed. With this, a certain amount of improvements were done. But it is limited to files which are less than 300MB or so. For files which are over GBs, it is just crawling and pathetic. Wondering if there is any better way to handle these large files in a better way so that the user need not wait for hours? Will a buffered read and caching the decoded information in a temporary files using a thread would help? How can we make sure that the GUI doesn't hang during these intensive parsing process? Really appreciate your suggestions. Thanks Vikas

        _ Offline
        _ Offline
        _Superman_
        wrote on last edited by
        #3

        You could do memory mapping for the file segments. You should get hold of a good profiler and check where the actual bottle neck is.

        «_Superman_» I love work. It gives me something to do between weekends.

        1 Reply Last reply
        0
        • V Vikas K

          Hi, I'm working on an application where it loads a huge file (like 4-6GB) and parses the file, searching for regular expressions, converting from Hex to Human readable form, filters etc. Since the file is of very large size, I'm facing lot of performance issues where it takes hours to process and show the file information in a window. To overcome this, what I did is, break the entire file into logical segments of 1 MB each and process 3 segments at a time. When the user is scrolling, the next segments will be processed. With this, a certain amount of improvements were done. But it is limited to files which are less than 300MB or so. For files which are over GBs, it is just crawling and pathetic. Wondering if there is any better way to handle these large files in a better way so that the user need not wait for hours? Will a buffered read and caching the decoded information in a temporary files using a thread would help? How can we make sure that the GUI doesn't hang during these intensive parsing process? Really appreciate your suggestions. Thanks Vikas

          N Offline
          N Offline
          Nishad S
          wrote on last edited by
          #4

          Vikas K. wrote:

          How can we make sure that the GUI doesn't hang during these intensive parsing process?

          What about using a worker thread?

          - ns ami -

          1 Reply Last reply
          0
          • V Vikas K

            Hi, I'm working on an application where it loads a huge file (like 4-6GB) and parses the file, searching for regular expressions, converting from Hex to Human readable form, filters etc. Since the file is of very large size, I'm facing lot of performance issues where it takes hours to process and show the file information in a window. To overcome this, what I did is, break the entire file into logical segments of 1 MB each and process 3 segments at a time. When the user is scrolling, the next segments will be processed. With this, a certain amount of improvements were done. But it is limited to files which are less than 300MB or so. For files which are over GBs, it is just crawling and pathetic. Wondering if there is any better way to handle these large files in a better way so that the user need not wait for hours? Will a buffered read and caching the decoded information in a temporary files using a thread would help? How can we make sure that the GUI doesn't hang during these intensive parsing process? Really appreciate your suggestions. Thanks Vikas

            S Offline
            S Offline
            Stuart Dootson
            wrote on last edited by
            #5

            I've had pretty good performance with memory mapped files (I've only used files up to about 1GB). What you need to do is create a file mapping with CreateFileMapping and then use MapViewOfFile to map segments of the file. I worked with 16MB windows on the file, which actually meant I mapped 32MB at a time, 16MB before and after the nominal file offset, so that negative random accesses from the file offset didn't fault over into the previous window - something like the diagram below:

            +----------------+----------------+
            | | |
            | | |
            | | |
            +----------------+----------------+
            ^ ^ ^
            | | |
            -16MB Requested +16MB
            offset into file

            I packaged this up into a MemoryMappedFile class which had an associated randomly-access iterator class (like a vector has an iterator). The memory mapped file could only be accessed using the iterator, which was exposed using 'begin' and 'end' methods of the memory mapped file class. On a reasonable workstation (2.4GHz Core 2 Duo), I could traverse the file at around 100MB/second when counting data packets whose size was roughly 200 bytes.

            Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

            V 1 Reply Last reply
            0
            • S Stuart Dootson

              I've had pretty good performance with memory mapped files (I've only used files up to about 1GB). What you need to do is create a file mapping with CreateFileMapping and then use MapViewOfFile to map segments of the file. I worked with 16MB windows on the file, which actually meant I mapped 32MB at a time, 16MB before and after the nominal file offset, so that negative random accesses from the file offset didn't fault over into the previous window - something like the diagram below:

              +----------------+----------------+
              | | |
              | | |
              | | |
              +----------------+----------------+
              ^ ^ ^
              | | |
              -16MB Requested +16MB
              offset into file

              I packaged this up into a MemoryMappedFile class which had an associated randomly-access iterator class (like a vector has an iterator). The memory mapped file could only be accessed using the iterator, which was exposed using 'begin' and 'end' methods of the memory mapped file class. On a reasonable workstation (2.4GHz Core 2 Duo), I could traverse the file at around 100MB/second when counting data packets whose size was roughly 200 bytes.

              Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

              V Offline
              V Offline
              Vikas K
              wrote on last edited by
              #6

              Thank you for your suggestions. Willwork on them and update :) .

              1 Reply Last reply
              0
              Reply
              • Reply as topic
              Log in to reply
              • Oldest to Newest
              • Newest to Oldest
              • Most Votes


              • Login

              • Don't have an account? Register

              • Login or register to search.
              • First post
                Last post
              0
              • Categories
              • Recent
              • Tags
              • Popular
              • World
              • Users
              • Groups