Improve unsupported coercion performance by optionally caching error #23
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As identified in #16 and jruby/jruby#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 -- 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):
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 Performance regression when going from 9.1.7.0 to 9.1.8.0 with virtus gem jruby/jruby#4540)