[
{
"Id": "176314",
"ThreadId": "52466",
"Html": "I'm using the latest Stable build 1.7.
\r\n
\r\nI have an index file in the root folder that maps out different files in one sub directory.
\r\nI read the index file using OpenReader and while traversing the index file I read the individual files using further OpenReader entries
\r\n
\r\nIn my test case I have 10000 files.. I am clocking each individual iteration and i see a slow degradation of performance.
\r\n
\r\nIs there an suggestions on how to do this kind of reading without degradation?
\r\n
\r\nZipEntry entry = zip[fileName];
\r\nCrcCalculatorStream stream = entry.OpenReader();
\r\n{
\r\n persit.Load(stream);
\r\n}
\r\n
\r\nThis method is much faster than extracting the whole zip file to a temporary directory and then reading the individual files.
\r\n",
"PostedDate": "2009-04-06T14:11:41.41-07:00",
"UserRole": null,
"MarkedAsAnswerDate": null
},
{
"Id": "176513",
"ThreadId": "52466",
"Html": "add a "using" statement. It will close the streams.\r\n",
"PostedDate": "2009-04-07T02:22:17.203-07:00",
"UserRole": null,
"MarkedAsAnswerDate": null
},
{
"Id": "176692",
"ThreadId": "52466",
"Html": "I already tried that. But then I looked at the source code for the CrcCalculatorStream. It doesn't implement Close and Dispose. I might be overlooking something here, but I see some of the other Stream classes like DeflateStream implements Close but not Dispose. I am not sure if this is the cause of the problem or if it's getting closed elsewhere.
\r\n
\r\nAlso the other questions is if I can use OpenReader simultaneously on two ZipEntries without closing the call to the first.
\r\n",
"PostedDate": "2009-04-07T10:12:39.997-07:00",
"UserRole": null,
"MarkedAsAnswerDate": null
},
{
"Id": "179889",
"ThreadId": "52466",
"Html": "This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.",
"PostedDate": "2009-04-15T18:17:46.033-07:00",
"UserRole": null,
"MarkedAsAnswerDate": null
},
{
"Id": "179892",
"ThreadId": "52466",
"Html": "I believe you cannot use OpenReader() on more than one ZipEntry at a time. The OpenReader() is essentially a wrapper on the read-only stream on the zip file. The way it works is the library does a Seek() on the internal stream, then opens the DeflateStream on that. For the CrcCalculatorStream() returned from the OpenReader() to work properly, you cannot move the cursor on the zipfile stream while you are reading. Every time you call OpenReader(), the cursor on the zipfile stream is set. The conclusion is: use only a single CrcCalculatorStream from OpenReader(), at a time.
\r\n
\r\nWhat I can suggest is to read in the entire index first, and then use OpenReader() on each successive entry. If the index is very large, you could extract it to a file, and then use a separate stream to read it. If you don't like that idea, you could open two ZipFile() instances using the same filesystem file. Call OpenReader() on the index with the first ZipFile, and then call OpenReader() on other entries using the 2nd instance of the ZipFile.
\r\n
\r\nIn any case, for a given ZipFile instance, you can use only one CrcCalculatorStream returned from an OpenReader() call, at a time.
\r\n
\r\n----
\r\n
\r\nThere is another possible explanation of the increase in time for each iteration when using OpenReader(). The implementation of OpenReader() seeks on the ZipFile stream. It could be that on successive calls to OpenReader(), the Seek() takes increasingly longer amounts of time. But this would be a surprise, because Seek() is going to be fast, in comparison to a DeflateStream.
\r\n
\r\nCan you tell me where the additional time is consumed on successive intervals? is it in the OpenReader() call, or is it in the actual read and extract operation?
\r\n
\r\n",
"PostedDate": "2009-04-15T18:29:46.263-07:00",
"UserRole": null,
"MarkedAsAnswerDate": null
}
]