"Neil Mitchell" writes:

I think it is known that Parsec 3 is slower than Parsec 2, as a result of the increased generality. I know that in the past someone was working on it, but I am not sure if they ever got anywhere.

I got pretty good performance (IMHO - about 10MB/s, still CPU-bound) using a lazy bytestring tokenizer and Parsec on top of that. Of course, it probably depends on the complexity of the parsing... -k -- If I haven't seen further, it is by standing in the footprints of giants

Philippa Cowderoy wrote:

On Tue, May 13, 2008 5:53 am, Neal Alexander wrote:

...

I can post the full profiling info if anyone really cares.

Any info is helpful. It's taking a while to get round to things, but the more relevant info we have to hand when we do the easier it is to improve things and the less begging for data we have to do!

I stripped the code down to just the parsec related stuff and retested it. http://72.167.145.184:8000/parsec_test/Parsec2.prof http://72.167.145.184:8000/parsec_test/Parsec3.prof And the parser with a 9mb (800 kb gziped) sample log file: http://72.167.145.184:8000/parsec_test.tar.gz

Hello Antoine, Wednesday, May 14, 2008, 8:43:47 AM, you wrote:

Is this expected? I don't really understand why adding an extra layer of indirection should speed things up.

adding laziness may improve performance by avoiding calculation of unnecessary stuff or moving into into later stage when it will be immediately consumed -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On Sun, May 18, 2008 at 11:23 AM, Antoine Latter wrote:

Neal, those two profiling results aren't really comparable, because your Parsec2 profiling doesn't include any cost-centers from the Parsec library - so all of the costs associated with Parsec2 will be assigned to cost-centers in EQ2Parse.

Self-reply: Or is it possible that Parsec2 is so much faster that it doesn't even show up in the .prof results? + The largest cost center in the Parsec2 results is the EQ2Parse function "until" + The largest cost center in the Parsec3 result is the Parsec function "manyTill", which (in the prof results) is only called by "until" in EQ2Parse. Which is consistent with my previous reasoning, at least. Antoine

Antoine Latter wrote:

On Tue, May 13, 2008 at 9:23 PM, Neal Alexander wrote:

...

I stripped the code down to just the parsec related stuff and retested it.

http://72.167.145.184:8000/parsec_test/Parsec2.prof http://72.167.145.184:8000/parsec_test/Parsec3.prof

And the parser with a 9mb (800 kb gziped) sample log file: http://72.167.145.184:8000/parsec_test.tar.gz

Neal, those two profiling results aren't really comparable, because your Parsec2 profiling doesn't include any cost-centers from the Parsec library - so all of the costs associated with Parsec2 will be assigned to cost-centers in EQ2Parse.

I've tried running this profiling on my own computer, and using the same Cabal options for Parsec2 as Parsec3, I never seem to get CAFs from Parsec2 to show up in the profiling result this this test.

Can anyone help me out?

I configure parsec (2 and 3) as follows: $ runghc Setup.hs configure --prefix=${HOME}/usr --enable-library-profiling --user --enable-optimization

and then I build the "Main" as follows: $ ghc --make -O2 -prof -auto Main -package parsec-2.1.0.0 - or - $ ghc --make -O2 -prof -auto Main

And I run main as: $ ./Main +RTS -p -RTS

When I specify the parsec-2.1.0.0 on the command-line, the Main.prof doesn't include any parsec CAFs.

Thanks, Antoine

Sorry about that. Hopefully this fixes it: http://72.167.145.184:8000/parsec_test/Parsec2_02.prof