<div dir="ltr">I forgot to mention that the memory consumption is several times higher than file size. On 8,3 Mb file:<br>> 532 MB total memory in use (4 MB lost due to fragmentation).<br><br>Having that 8 Mb in memory is not the problem. 532 Mb is another story. In general, the program consumes roughly 64 times more memory than file size and it scales linearly.<br>
<br><br>Best regards<br>Christopher Skrzętnicki<br><br><div class="gmail_quote">On Sat, Jul 19, 2008 at 9:52 PM, Chaddaï Fouché <<a href="mailto:chaddai.fouche@gmail.com">chaddai.fouche@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2008/7/19 Krzysztof Skrzętnicki <<a href="mailto:gtener@gmail.com">gtener@gmail.com</a>>:<br>
> Hi all<br>
<div class="Ih2E3d">><br>
> 1) Profiling shows that very simple functions are source of great memory and<br>
> time consumption. However, if I turn them off and simply print their input<br>
> arguments instead, the overall time and memory consumption doesn't change.<br>
> But now another function is acting badly. My guess: somehow the cost of<br>
> Parsec code is shifted into whatever function is using it's output. Let's<br>
> see:<br>
<br>
</div>Are you using Parsec to parse the whole file ? Then your problem is<br>
there : Parsec needs to read and process the whole file before it can<br>
give us any output since it thinks it could have to give us an error<br>
instead and it can't be sure of that before he has read the whole<br>
thing...<br>
In your case, your problem is such that you would prefer to treat the<br>
file as a stream, isn't it ?<br>
There are some parser library that can give output lazily (look at<br>
polyparse flavour), another option would be to only use Parsec where<br>
you need it and just read and print the ordinary text for example.<br>
<font color="#888888"><br>
--<br>
Jedaï<br>
</font></blockquote></div><br></div>