good find, definitely makes sense to look into "optimizing" match? at least the way MRI does ...
shouldn't be too hard - split out a method or introduce a boolean parameter on the internals to not set $~

MRI has separate internal implementation for that which passes region as NULL so we'd have to make something similar in joni.

@lopex and I looked at this one today. Removing creating internal regions in joni and then deleting a bunch of code on JRuby side (since we don't need to deal with captures) MRI (2.5.1) was like 5.2M i/s and we were like 4.7-4.9M i/s from like 1.9-2.1M i/s before patching. If I removed interruptible support we went up to about 5.5M i/s. If I tried bench with those changes using graal ce rc4 we get about 7.2M i/s.

@lopex plans on doing a cleaner version of my changes to joni and we will at least close the gap quite a bit.

Even without removing regions we discovered we were calling search instead of match (which we had to call based on the current version of what match? calls through; but we ended up finding two bottlenecks overall so this was somewhat satisfying.

posterity diffs: https://gist.github.com/enebo/ef854d4f4929c5484660aa6453e99b2c https://gist.github.com/enebo/ad593950c5b5788616afd6e1ee499502

We are closer but still not quite there (numbers from my MBP):

[] ~/projects/jruby $ jruby blah.rb
Warming up --------------------------------------
               match    93.104k i/100ms
              match?   132.259k i/100ms
Calculating -------------------------------------
               match      2.204M (± 9.7%) i/s -     10.893M in   5.009938s
              match?      3.104M (± 6.3%) i/s -     15.474M in   5.009289s

[] ~/projects/jruby $ rvm ruby-2.5 do ruby blah.rb
Warming up --------------------------------------
               match    71.941k i/100ms
              match?   222.292k i/100ms
Calculating -------------------------------------
               match    917.639k (± 5.0%) i/s -      4.604M in   5.032212s
              match?      4.885M (± 2.1%) i/s -     24.452M in   5.007808s

[] ~/projects/jruby $ jruby -Xcompile.invokedynamic blah.rb
Warming up --------------------------------------
               match   106.672k i/100ms
              match?   152.679k i/100ms
Calculating -------------------------------------
               match      2.565M (±10.5%) i/s -     12.694M in   5.030781s
              match?      3.712M (± 6.3%) i/s -     18.474M in   5.003471s

FWIW here's an allocation profile of the match? call from the above benchmark run an arbitrary number of times. The vast majority of allocations are the Joni engine and its int[] state.

          percent          live          alloc'ed  stack class
 rank   self  accum     bytes objs     bytes  objs trace name
    1 61.37% 61.37%  38246880 239043 2637534560 16484591 377572 org.joni.ByteCodeMachine
    2 18.41% 79.79%  11474016 239042 791260272 16484589 377574 int[]
    3  0.90% 80.69%    562256 10216    562256 10216 300000 char[]
    4  0.39% 81.08%    245464 10206    245464 10206 300000 java.lang.String
    5  0.31% 81.39%    193472 4233    193472  4233 300000 java.lang.Object[]
    6  0.16% 81.55%     99016  387     99016   387 307282 byte[]
    7  0.15% 81.70%     94464 1968     94560  1970 343568 org.jruby.RubySymbol
    8  0.13% 81.83%     80512  629     80512   629 345011 org.jruby.ir.IRMethod
    9  0.13% 81.96%     78920 1973     79000  1975 343569 org.jruby.util.ByteList
   10  0.12% 82.08%     77600 1940     77600  1940 343562 org.jruby.util.ByteList

Since we might be beaten by GC pressure here and MRI just mallocs/frees stack and repeat stack (we're allocating matcher and repeat stack) Is there possibly a mix of thread local / dynamic scope place where we could reuse the matcher instance ?

@lopex it would be interesting as a test to see how much difference that makes...like just cheat with the impl to cache matcher and see if we get considerably faster.

I have experimented with resetting and reusing the matcher, but the machine itself still constructed a lot of state. If we could reuse the entire thing I'm sure it would have an impact, but I was never able to measure that.

But it shouldnt though, Matcher should be all state there is