To workaround this problem, this PR adds the option (controlled by the setting the COERCIBLE_CACHE_UNSUPPORTED_COERCION_ERROR environment variable to '1', off by default) to reuse a cached error object, rather than raising a new instance every time.
This saves a big slice of the cost of using errors, but trades it off with having a useless backtrace -- all UnsupportedCoercion errors will share the same backtrace.
It also includes a benchmark that can be used to measure the impact of this change. Here are some results of the benchmark on my local machine (Core i7-6500U, Ubuntu 17.04):
As identified in https://github.com/solnic/coercible/issues/16 and https://github.com/jruby/jruby/issues/4540, coercible's use of errors to signal unsupported coercions has a measurable impact on performance, especially when using JRuby.
To workaround this problem, this PR adds the option (controlled by the setting the
COERCIBLE_CACHE_UNSUPPORTED_COERCION_ERROR
environment variable to'1'
, off by default) to reuse a cached error object, rather than raising a new instance every time. This saves a big slice of the cost of using errors, but trades it off with having a useless backtrace -- allUnsupportedCoercion
errors will share the same backtrace.It also includes a benchmark that can be used to measure the impact of this change. Here are some results of the benchmark on my local machine (Core i7-6500U, Ubuntu 17.04):
ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-linux]
:jruby 9.1.7.0 (2.3.1) 2017-01-11 68056ae Java HotSpot(TM) 64-Bit Server VM 25.131-b11 on 1.8.0_131-b11 +indy +jit [linux-x86_64]
:jruby 9.1.12.0 (2.3.3) 2017-06-15 33c6439 Java HotSpot(TM) 64-Bit Server VM 25.131-b11 on 1.8.0_131-b11 +indy +jit [linux-x86_64]
(The difference here to 9.1.7.0 is due to the "regression" in https://github.com/jruby/jruby/issues/4540)