Closed Bug 1398153 Opened 7 years ago Closed 7 years ago

nsRange::DoSetRange is AddRef/Release heavy

Categories

(Core :: DOM: Core & HTML, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla57
Tracking Status
firefox57 --- fixed

People

(Reporter: smaug, Assigned: smaug)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

I think we don't need to addref/release so much if containers aren't changing.
Attached patch dosetrange.diff (deleted) — Splinter Review
Attachment #8905952 - Flags: review?(amarchesini)
Comment on attachment 8905952 [details] [diff] [review] dosetrange.diff Review of attachment 8905952 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/base/nsRange.h @@ +598,5 @@ > > template<typename A, typename B> > RangeBoundaryBase& operator=(const RangeBoundaryBase<A,B>& aOther) > { > + if (mParent != aOther.mParent) { Please, write a comment saying why this is needed.
Attachment #8905952 - Flags: review?(amarchesini) → review+
Pushed by opettay@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/d8ce26333a8b Try to Release/AddRef a bit less in nsRange::DoSetRange, r=baku
Is is possible that we should just be using move assignment in the hot places this gets called, instead of copy assignment?
How would that help? And note, this is a case where a raw pointer is assigned to a nsCOMPtr
Oh, I see. Templated copy assignment, bleh. You're right, it wouldn't do anything for raw assignment to nsCOMPtr. But in the nsCOMPtr assignment case, move assignment (or even writing out the actual copy assignment operator to handle that case, since the templated one won't be called in that case) would be beneficial.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: