Issue #14490 has been updated by k0kubun (Takashi Kokubun).

Assignee set to k0kubun (Takashi Kokubun)

Yes, I recognize this problem and will investigate the cause for sure. I don't know a clear cause for this yet.

> I suspect this is happening cause we are introducing new overhead to every single method dispatch (counting for mjit, and hash lookup and so on). This overhead adds up.

My understanding of new overheads: JIT enqueue on 5 total calls, total calls count up (sometimes it happens twice for now), JIT-ed C function call instead continueing in the same VM, and additional VM invocation for not JIT-ed methods or JIT cancel. Some of those overheads might grow in Rails. I need investigation.

I'm not sure what's hash lookup.

----------------------------------------
Bug #14490: MJIT slows down Rails applications
https://bugs.ruby-lang.org/issues/14490#change-70415

* Author: sam.saffron (Sam Saffron)
* Status: Open
* Priority: Normal
* Assignee: k0kubun (Takashi Kokubun)
* Target version: 
* ruby -v: 
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
This was reported earlier but I would like to add some test methodology here: (tested using Discourse)

### What I tested

1. Run `ruby script/bench.rb` to warm up profiling database

2. Run `RUBYOPT='--jit --jit-verbose=1 --jit-max-cache=10000' RAILS_ENV=profile bin/puma -e production`

   1. Increasing the cache size is an attempt to get higher hit rates

3. WAIT 5-15 or so minutes for all jitting to stop so we have no cross talk

4. Run `ab -n 100 http://localhost:9292/`

5. Wait for all new jitting to finish

6. Run `ab -n 100 http://localhost:9292/`


The absolute best I get is around **61ms** median for the test. With MJIT

This is MJIT results!

```
Percentage of the requests served within a certain time (ms)
  50%     61
  66%     63
  75%     70
  80%     71
  90%     73
  95%     83
  98%    106
  99%    109
 100%    109 (longest request)

```

Compared to w/o MJIT which is:


```
Percentage of the requests served within a certain time (ms)
  50%     47
  66%     48
  75%     50
  80%     51
  90%     60
  95%     62
  98%     75
  99%     77
 100%     77 (longest request)

```  


### Theory on why this happens

I suspect this is happening cause we are introducing new overhead to every single method dispatch (counting for mjit, and hash lookup and so on). This overhead adds up.






-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>