Thanks for your comments John. <div>I appreciate your work.  I think pandoc is fantastic! </div><div><br></div><div>I&#39;m interested to solve this problem, but time is also an issue.</div><div>I&#39;ll try to toy around with it.</div>
<div><br></div><div>Thanks,</div><div><br></div><div>Pieter</div><div><br></div><div><br></div><div><br><div class="gmail_quote">On Tue, Aug 10, 2010 at 7:06 PM, John MacFarlane <span dir="ltr">&lt;<a href="mailto:jgm@berkeley.edu">jgm@berkeley.edu</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi all,<br>
<br>
I&#39;m the author of zip-archive. I wrote it for a fairly special purpose --<br>
I wanted to create and read ODT files in pandoc -- and I know it could be<br>
improved.<br>
<br>
The main problem is that the parsing algorithm is kind of stupid; it just<br>
reads the whole archive in sequence, storing the files as it comes to them.<br>
So a file listing will take almost as much time as a full extract.<br>
<br>
There&#39;s a better way: The zip archive ends with an &quot;end of central directory<br>
record&quot;, which contains (among other things) the offset of the central<br>
directory from the beginning of the file. So, one could use something like the<br>
following strategy:<br>
<br>
1. read the &quot;end of central directory record&quot;, which should be the last 22<br>
bytes of the file. I think it should be possible to do this without allocating<br>
memory for the whole file.<br>
<br>
2. parse that to determine the offset of the central directory.<br>
<br>
3. seek to the offset of the central directory and parse it. This will give<br>
you a list of file headers. Each file header will tell you the name of a file<br>
in the archive, how it is compressed, and where to find it (its offset) in the<br>
file.<br>
<br>
At this point you&#39;d have the list of files, and enough information to seek to<br>
any file and read it from the archive. The API could be changed to allow lazy<br>
reading of a single file without reading all of them.<br>
<br>
I don&#39;t think these changes would be too difficult, since you wouldn&#39;t have to<br>
change any of the functions that do the binary parsing -- it would just be a<br>
matter of changing the top-level functions.<br>
<br>
I don&#39;t have time to do this right now, but if one of you wants to tackle the<br>
problem, patches are more than welcome! There&#39;s some documentation on the ZIP<br>
format in comments in the source code.<br>
<br>
John<br>
<br>
<br>
+++ Neil Brown [Aug 10 10 12:35 ]:<br>
<div><div></div><div class="h5">&gt; On 10/08/10 00:29, Pieter Laeremans wrote:<br>
&gt; &gt;Hello,<br>
&gt; &gt;<br>
&gt; &gt;I&#39;m trying some haskell scripting. I&#39;m writing a script to print<br>
&gt; &gt;some information<br>
&gt; &gt;from a zip archive.  The zip-archive library does look nice but<br>
&gt; &gt;the performance of zip-archive/lazy bytestring<br>
&gt; &gt;doesn&#39;t seem to scale.<br>
&gt; &gt;<br>
&gt; &gt;Executing :<br>
&gt; &gt;<br>
&gt; &gt;   eRelativePath $ head $ zEntries archive<br>
&gt; &gt;<br>
&gt; &gt;on an archive of around 12 MB with around 20 files yields<br>
&gt; &gt;<br>
&gt; &gt;Stack space overflow: current size 8388608 bytes.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;The script in question can be found at :<br>
&gt; &gt;<br>
&gt; &gt;<a href="http://github.com/plaeremans/HaskellSnipplets/blob/master/ZipList.hs" target="_blank">http://github.com/plaeremans/HaskellSnipplets/blob/master/ZipList.hs</a><br>
&gt; &gt;<br>
&gt; &gt;I&#39;m using the latest version of haskell platform.  Are these<br>
&gt; &gt;libaries not production ready,<br>
&gt; &gt;or am I doing something terribly wrong ?<br>
&gt;<br>
&gt; I downloaded your program and compiled it (GHC 6.12.1, zip-archive<br>
&gt; 0.1.1.6, bytestring 0.9.1.5).  I ran it on the JVM src.zip (20MB,<br>
&gt; ~8000 files) and it sat there for a minute (67s), taking 2.2% memory<br>
&gt; according to top, then completed successfully.  Same behaviour with<br>
&gt; -O2.  Which compares very badly in time to the instant return when I<br>
&gt; ran unzip -l on the same file, but I didn&#39;t see any memory problems.<br>
&gt; Presumably your archive is valid and works with unzip and other<br>
&gt; tools?<br>
&gt;<br>
&gt; Thanks,<br>
&gt;<br>
&gt; Neil.<br>
&gt;<br>
</div></div><div><div></div><div class="h5">&gt; _______________________________________________<br>
&gt; Haskell-Cafe mailing list<br>
&gt; <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
&gt; <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Pieter Laeremans &lt;<a href="mailto:pieter@laeremans.org">pieter@laeremans.org</a>&gt;<br><br>&quot;The future is here. It&#39;s just not evenly distributed yet.&quot;  W. Gibson<br>

</div>