On Fri, 2010-02-12 at 12:51 +0000, John Lato wrote:
Yes, the remaining part will be returned, but the consumed portion is lost. I couldn't figure out how to solve that problem other than cacheing everything.
I decided to post the new code on webpage (http://www.doc.ic.ac.uk/~mmp08/iteratee/) to not spam everyone's inbox. I think you want something more like safeParsecIteratee from my code. From the same CPU more random numbers (I wonder how they'll look like in a month when BS problems will be resolved). For ByteString: Maciej's Maciej's Safe John's Short parser 5: 0.000144s 0.000040s 0.000067s 10: 0.000052s 0.000042s 0.000048s 15: 0.000053s 0.000052s 0.000061s 20: 0.000041s 0.000033s 0.000039s 50: 0.000054s 0.000049s 0.000111s 100: 0.000082s 0.000101s 0.000254s 1000: 0.000610s 0.000623s 0.014414s 10000: 0.007069s 0.007947s 1.197706s 100000: 0.058025s 0.057382s 117.231680s Short failing parser 5: 0.000104s 0.000030s 0.000026s 10: 0.000028s 0.000024s 0.000023s 15: 0.000026s 0.000025s 0.000031s 20: 0.000027s 0.000028s 0.000025s 50: 0.000027s 0.000025s 0.000042s 100: 0.000026s 0.000024s 0.000023s 1000: 0.000024s 0.000023s 0.000023s 10000: 0.000259s 0.000025s 0.000022s 100000: 0.000025s 0.000039s 0.000024s Failing parser 5: 0.000025s 0.000024s 0.000022s 10: 0.000027s 0.000024s 0.000026s 15: 0.000028s 0.000028s 0.000031s 20: 0.000032s 0.000045s 0.000038s 50: 0.000045s 0.000045s 0.000096s 100: 0.000069s 0.000144s 0.000228s 1000: 0.000544s 0.000512s 0.013124s 10000: 0.004760s 0.004695s 1.240703s 100000: 0.046858s 0.046897s 119.860964s For []: Maciej's Maciej's Safe John's Short parser 5: 0.000215s 0.000141s 0.000541s 10: 0.000054s 0.000286s 0.000178s 15: 0.000046s 0.000078s 0.000248s 20: 0.000130s 0.000050s 0.000420s 50: 0.000066s 0.000200s 0.000785s 100: 0.000176s 0.000240s 0.001522s 1000: 0.000826s 0.000857s 0.014399s 10000: 0.006674s 0.007185s 0.381615s 100000: 0.062452s 0.065178s 31.454621s Short failing parser 5: 0.000210s 0.000054s 0.000099s 10: 0.000096s 0.000037s 0.000104s 15: 0.000059s 0.000039s 0.000184s 20: 0.000038s 0.000036s 0.000114s 50: 0.000037s 0.000100s 0.000111s 100: 0.000165s 0.000037s 0.000103s 1000: 0.000079s 0.000036s 0.000103s 10000: 0.000037s 0.000037s 0.000179s 100000: 0.000037s 0.000168s 0.000104s Failing parser 5: 0.000037s 0.000090s 0.000089s 10: 0.000157s 0.000055s 0.000169s 15: 0.000062s 0.000039s 0.000303s 20: 0.000043s 0.000194s 0.000311s 50: 0.000183s 0.000056s 0.000780s 100: 0.000080s 0.000172s 0.001624s 1000: 0.000714s 0.000714s 0.014076s 10000: 0.005451s 0.006890s 0.379960s 100000: 0.052609s 0.055770s 31.537776s The timings where about the same in every run. Also it seems that keeping reference to input does not create significant slow-down if it is not an artefact of testing method. Short failing parser probably have somewhere an error.
Interesting. I expect good performance as long as chunks don't need to be concatenated. The default chunk size is either 4096 or 8192 (I don't remember ATM). This also assumes that no intervening functions (take, drop, etc.) alter the stream too significantly. Testing 1e5 wouldn't do more than two concats, and particularly with bytestrings shouldn't impose too much penalty. List performance would be much worse though.
With 1e5 it should have 1e5/(4e3 or 8e3) \approx 10-20 concats.
Regards PS. Why iteratee uses transformers? It seems to be identical (both have functional dependencies etc.) to mtl except that mtl is standard in platform. Using both lead to clashes between names.
Short answer: I am using iteratee with another package that uses transformers. Longer answer: see discussions on mtl vs. transformers in the haskell-libraries archive.
I'll read them. I will ask one more question regarding iteratee. Why StreamChunk have 10 methods which already are in ListLike? Regards