jruby improvements + weaker xpath caching #1597
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thank you for submitting this, @kares! Can you please rebase this off current master? It doesn't have 92768e0 in it, so the CI pipeline is failing when testing against libxml system libraries. See https://ci.nokogiri.org/teams/nokogiri-core/pipelines/nokogiri/jobs/ruby-2.4-system-pr/builds/3 for specifics. |
no need for a synchronized Hashtable here; size will be 4 99% of time
... loading reflectively makes no sense since the class is already loaded as its part of the method's signature (return type)
has been introduced before the xalan .jars where packed with the gem it was only necessary due changing Java version - no longer the case!
... from JRuby's RubyHash API so that we avoid all is1_9() checks
... much safer to reason about AND REVEALED SOME INTERNAL ISSUES !
... also re-format code spacing to match rest of the file
... (temporarily) removed the existing caching mechanism
we now make sure to only cache xpaths without binds or custom handlers ... it has been disabled in previous commit(s)
... since there's logic everywhere dealing with the case also do NOT initialize nodes with newEmptyArray and than append to it
... to potentially save one piece of (char[]) array copy-ing
(incl. previous commits) causes notably less garbage generation!
also faster due re-using a thread-cached encoder (resolves sparklemotion#1440)
also use enum values instead of wrapping it to a set (to find encoding)
kares
force-pushed
the
jruby-review-4x
branch
from
830e5ea
to
377dde4
Compare
This was referenced Feb 10, 2017
|
rebased and all 💚 now ... thanks for the feedback. numbers show that doc parsing is ~ 10% faster + xpath has gone 2x faster in some of the cases I tested. |
|
Yep, about to merge! Just writing CHANGELOG entries now. Thanks so much! |
|
Merged manually.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
managed to run into more common problems such as cloning non-cloneable (Java) objects.
a bit ugly pattern in general but for the rest of Ruby object cloning it would need a justification.
further I realized some xpath problems :
Integerwas not supported (resolved xpath function returning an int fails under jruby #1595)this is now avoided (such expressions always create a new xpath context) - they are less common.
xpath(expr)still caches as before, but I realized the cache makesxpath()not thread-safe #1596UPDATE: also added a fix for #1440 (also resolves #1281 which is a duplicate - had the same cause)