Iteratee and parsec (was: Re: [Haskell-cafe] Re: Haskell-Cafe Digest, Vol 78, Issue 14)

Maciej Piechotka uzytkownik2 at gmail.com
Fri Feb 12 14:27:10 EST 2010


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20100212/3b93ff43/attachment.bin


More information about the Haskell-Cafe mailing list