On Sat, Jan 18, 2014 at 6:42 PM, Jeffrey Kegler < [email protected]> wrote:
> This is from MarpaX::Demo::JSONParser, right? That gives you a choice > of two grammars, and if you chose mine, it was written for benchmarking > with long input strings, so I wasn't optimizing for repeated parses of > short strings. There's also Peter Stuifzand's grammar, and Peter's > intentions were probably more practical. > This is a 'fork' of cpan/s/sl_json.t so the grammar must be yours. MarpaX::Demo::JSONParser is now Ron Savage's module, so if you're > interested in changes to it, you should talk to Ron. > Sure, but my thinking was more about MarpaX::Languages::JSON::Benchmark — a benchmark for Marpa valuator options (ASF::traverse(), AST with newly implemented action => *[lhs, value(s)] *and traverse(), bless_package, semantic_package, and a THIF-based parser based on existing grammar I was thinking of writing) vs other parsing techniques and JSON looked like a good target with JSON::XS, JSON::PP. First I planned to make Marpa-based parsers to pass JSON::XS|PP test suite and use some big file (like this<https://github.com/zeMirco/sf-city-lots-json>) to test how execution time/memory grows with size. Looks like a good exercise for Marpa? > > --jeffrey > > On 01/18/2014 03:00 AM, Ruslan Shvedov wrote: > > Is it intended that the JSON grammar is not reused? The script would 2 > times faster if it were. > > > On Thu, Jan 16, 2014 at 8:53 PM, Jeffrey Kegler < > [email protected]> wrote: > >> $naif_recce->value() is being called to parse the JSON grammar, as >> opposed to the JSON itself. Note that with short strings, as in your >> examples, start-up costs play a greater role. -- jeffrey >> >> On 01/16/2014 08:26 AM, rns wrote: >> >> Devel::NYTProf says that both scripts spend much time in >> Marpa::R2::Recognizer::value — is it expected with ASF's? >> >> sl_json_asf >> >> Calls P F Exclusive >> Time Inclusive >> Time Subroutine 13 1 1 203ms 272ms Marpa::R2::Recognizer::value >> >> sl_json_no_trace >> Calls P F Exclusive >> Time Inclusive >> Time Subroutine 26 1 1 231ms 312ms Marpa::R2::Recognizer::value 1152 1 >> 1 105ms 152ms Marpa::R2::Internal::Grammar::add_user_rule >> >> >> On Thursday, January 16, 2014 5:55:55 PM UTC+2, rns wrote: >>> >>> I once thought that traversing ASF's can be a faster way of doing >>> semantics because ASF's *value() *is not called (actions are not >>> applied) and grammar can be absolutely syntactic, so I decided to try it >>> with *sl_json.t* from Marpa test suite (latest dev version, cygwin, >>> 5.14.2). >>> >>> Changes made to original sl_json.t from the test suite >>> >>> removed tracing test and code >>> >>> Writing semantics via ASF is like this: first I got the default >>> action that produced results as Perl data structure, dumped with YAML to >>> see what's there as needed and then added handlers via if/else. AST >>> semantics is easier because many handlers can be left to default. >>> >>> Changes made to the grammar after converting semantics to ASF >>> >>> remove all action adverbs >>> >>> removed events and changed read()/resume() loop to just read() >>> removed round brackets around literals >>> removed bless_package >>> >>> >>> The net result is that >>> sl_json_asf.t<https://gist.github.com/rns/8456567>is a bit slower than >>> sl_json_no_trace.t <https://gist.github.com/rns/8456626> when measured >>> with *time* and is equal within 2-3% when quickly and dirtily >>> Benchmark-ed [1]. So, now it looks like Perl overhead over libmarpa is >>> pretty much constant across all ways of doing semantics in Marpa::R2. >>> >>> Is it as expected or I missed something? >>> >>> I'm thinking about cheaper ASF traversing like the low-level synopsis >>> code in Marpa::R2::Glade. Makes sense? >>> >>> Good news, though, is that ASF semantics is not much slower, if a bit >>> harder to write. >>> >>> [1] >>> use Benchmark qw{ cmpthese }; >>> cmpthese(500, { >>> 'json_asf' => q{ eval `cat sl_json_asf.t` }, >>> 'json_no_trace' => q{ eval `cat sl_json_no_trace.t` }, >>> }); >>> >>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "marpa parser" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "marpa parser" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > You received this message because you are subscribed to the Google Groups > "marpa parser" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > You received this message because you are subscribed to the Google Groups > "marpa parser" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
