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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
