> I think it's just that ?<...> is slower than $n.  Could you try
> comparing my solution (the one based on yours) on both 1.8 and 1.9?

That's true of course (i_18 is the $n version):

    $ ruby benchmark_eric_mahurin.rb i_18
    "quiz155i_18"
    205653 chars/second

    $ ruby19 benchmark_eric_mahurin.rb i_18
    "quiz155i_18"
    271050 chars/second

    $ ruby19 benchmark_eric_mahurin.rb i
    "quiz155i"
    207100 chars/second

But just having the pleasure to be able to use more than 9 groups and
not to have to care about group order IMHO justifies the use of named
groups. It wasn't just once that I wasted time with searching for the
source of some problem just to find out that the group order changed
or
that the group numbers between, well, only mostly similar
programmatically generated regexps differed.

But the reason why I'm asking is that, e.g., your solution finishes
the
benchmark with 107323 chars/second when run with ruby18. With ruby19
though, it's astounishing 1703 chars/second. I'm not sure though what
is
causing this slowdown. Also I'm wondering if this isn't an artefact
of
the benchmark. The full run looks like this:

      user     system      total        real
...
8 24142  0.541000   0.000000   0.541000 (  0.601000)
9 25988  0.621000   0.000000   0.621000 (  0.641000)
10 588993246.555000  93.324000 339.879000 (345.657000)
1703 chars/second

So the slowdown only happens after Step #9.

My version that uses Regexp#match() (but still eval based) makes:

      user     system      total        real
...
7 3518  0.090000   0.000000   0.090000 (  0.120000)
8 24142  2.894000   0.010000   2.904000 (  2.934000)
8228 chars/second

But the time limit is exceeded at step #8 already. This makes me
wonder
what is causing this "interesting" behaviour of your solution at
step #10 when run with ruby19.


BTW, my own benchmarks (using random object generation of different
lenght based on Ara's proposal but slightly enhanced) show the
following
picture:


First the net timing spent on random object generation alone:
      user     system      total        real
10  2.003000   0.000000   2.003000 (  2.033000)
20  6.799000   0.000000   6.799000 (  6.940000)
30 17.636000   0.000000  17.636000 ( 17.786000)

10: n=10000 avg.size=47
20: n=10000 avg.size=159
30: n=10000 avg.size=406


"quiz155i" (my original submission)
      user     system      total        real
10  3.495000   0.000000   3.495000 (  3.535000)
20 10.024000   0.000000  10.024000 ( 10.095000)
30 25.988000   0.000000  25.988000 ( 26.027000)

10: n=10000 avg.size=46
20: n=10000 avg.size=148
30: n=10000 avg.size=391


"quiz155i_18" (modifyied for 18 compatibility)
      user     system      total        real
10  3.345000   0.000000   3.345000 (  3.385000)
20  9.964000   0.000000   9.964000 ( 10.014000)
30 24.455000   0.000000  24.455000 ( 24.506000)

10: n=10000 avg.size=47
20: n=10000 avg.size=157
30: n=10000 avg.size=396


"quiz155b" (json based, i.e. ragel-based C extension)
      user     system      total        real
10  2.263000   0.010000   2.273000 (  2.303000)
20  7.351000   0.000000   7.351000 (  7.391000)
30 18.636000   0.000000  18.636000 ( 18.687000)

10: n=10000 avg.size=46
20: n=10000 avg.size=156
30: n=10000 avg.size=399


"solution_paolo_bonzini.rb"
      user     system      total        real
10  4.226000   0.000000   4.226000 (  4.256000)
20 13.349000   0.000000  13.349000 ( 13.450000)
30 34.470000   0.070000  34.540000 ( 36.001000)

10: n=10000 avg.size=47
20: n=10000 avg.size=154
30: n=10000 avg.size=388


BTW I also measured steve's version of a treetop parser but with 1000
iterations only:

"solution_steve.rb"
      user     system      total        real
10  5.037000   0.000000   5.037000 (  5.068000)
20 14.651000   0.010000  14.661000 ( 14.961000)
30 40.298000   0.020000  40.318000 ( 41.330000)

10: n=1000 avg.size=48
20: n=1000 avg.size=148
30: n=1000 avg.size=407


What would the size of an average json snippet an ajax app has to deal
with be? I'm not in the webapp development buisness but from my
understanding this would be rather small, wouldn't it?

Regards,
Thomas.