From: takashikkbn@... Date: 2018-02-19T02:38:12+00:00 Subject: [ruby-core:85629] [Ruby trunk Bug#14490] MJIT slows down Rails applications Issue #14490 has been updated by k0kubun (Takashi Kokubun). > This was reported earlier but I would like to add some test methodology here: (tested using Discourse) Ah, somehow I didn't read this part. Thank you for sharing! I'm using the similar way. ---------------------------------------- Bug #14490: MJIT slows down Rails applications https://bugs.ruby-lang.org/issues/14490#change-70417 * 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: