Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix #1063: poor memory performance when duping DocumentFragment #1834

Merged
merged 5 commits into from
Dec 10, 2018

Conversation

flavorjones
Copy link
Member

See #1063 for background and why this is implemented for MRI and not JRuby. See related #1832 which is a placeholder for the JRuby work should we decide to do it.

because I'm about to add some behavior
This is an optimization of what's usually done, which is to make a
document-local duplicate via `#dup` followed by an `#add_child` or
similar. The drawback in that scheme, of course, is that unparented
nodes cannot be GCed and so occupy memory while the document is still
accessible.

Using this new variation of `#dup` we can create a duplicate in the
other document directly, without a direct clone.
because I don't have good evidence of high memory usage in the JRuby
implementation.
@flavorjones flavorjones added this to the v1.9.0 milestone Dec 10, 2018
@flavorjones flavorjones merged commit e2a4f6b into master Dec 10, 2018
@flavorjones flavorjones deleted the 1063-flavorjones-dup-document-fragment-attempt-2 branch December 10, 2018 05:37
flavorjones added a commit that referenced this pull request Dec 12, 2024
Back in b92660e (#1834 fixing #1063) I omitted support in JRuby for
the "new_parent_document" argument to `Node#dup` because there was no
performance reason to implement it. So the test was skipped.

However, in 1e7d38a and other commits in #3117 (fixing #316), I
introduced a call to `initialize_copy_with_args` that passes the new
parent document as an argument on both CRuby and JRuby
implementations. Because the test was skipped, I didn't catch that
this broke on JRuby.

In particular this was a problem for Loofah which relies on
decorators, and even more particularly this broke the
`Loofah::TextBehavior` formatting concern for
`Loofah::*::DocumentFragment` objects.

Maybe we should be running downstream tests with JRuby, too? But that
feels like a big investment right now so I'll avoid scarring on the
first cut, and wait to see if it happens again.
flavorjones added a commit that referenced this pull request Dec 12, 2024
Back in b92660e (#1834 fixing #1063) I omitted support in JRuby for
the "new_parent_document" argument to `Node#dup` because there was no
performance reason to implement it. So the test was skipped.

However, in 1e7d38a and other commits in #3117 (fixing #316), I
introduced a call to `initialize_copy_with_args` that passes the new
parent document as an argument on both CRuby and JRuby
implementations. Because the test was skipped, I didn't catch that
this broke on JRuby.

In particular this was a problem for Loofah which relies on
decorators, and even more particularly this broke the
`Loofah::TextBehavior` formatting concern for
`Loofah::*::DocumentFragment` objects.

Maybe we should be running downstream tests with JRuby, too? But that
feels like a big investment right now so I'll avoid scarring on the
first cut, and wait to see if it happens again.

(cherry picked from commit dda0be2)
flavorjones added a commit that referenced this pull request Dec 12, 2024
**What problem is this PR intended to solve?**

Back in b92660e (#1834 fixing #1063) I omitted support in JRuby for the
"new_parent_document" argument to `Node#dup` because there was no
performance reason to implement it. So the test was skipped.

However, in 1e7d38a and other commits in #3117 (fixing #316), I
introduced a call to `initialize_copy_with_args` that passes the new
parent document as an argument on both CRuby and JRuby implementations.
Because the test was skipped, I didn't catch that this broke on JRuby.

In particular this was a problem for Loofah which relies on decorators,
and even more particularly this broke the `Loofah::TextBehavior`
formatting concern for `Loofah::*::DocumentFragment` objects.


**Have you included adequate test coverage?**

The skipped test is no longer skipped!

Maybe we should be running downstream tests with JRuby, too? But that
feels like a big investment right now so I'll avoid scarring on the
first cut, and wait to see if it happens again.


**Does this change affect the behavior of either the C or the Java
implementations?**

Brings the Java impl into agreement with the C impl.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant