Closed Bug 697332 Opened 13 years ago Closed 4 years ago

Avoid allocating for the setPropertyAsAString() calls in the feed processor

Categories

(Core :: General, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: n.nethercote, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: [MemShrink:P2])

(Spun off from bug 697041.) DMD saw some reports like this: Unreported: 1,169,360 (cumulative: 522,935,088) bytes in 2,595 heap block(s) in record 54 of 27713: Requested bytes unreported: 963,290 / 963,290 Slop bytes unreported: 206,070 / 206,070 at 0x402A063: malloc (vg_replace_malloc.c:263) by 0x403C044: moz_malloc (mozalloc.cpp:113) by 0x7A71BB9: nsStringBuffer::Alloc(...) (nsSubstring.cpp:209) by 0x7A71F45: nsAString_internal::MutatePrep(...) (nsTSubstring.cpp:162) by 0x7A72018: nsAString_internal::ReplacePrepInternal(...) (nsTSubstring.cpp:198) by 0x7A718F3: nsAString_internal::ReplacePrep(...) (nsTSubstring.h:685) by 0x7A72445: nsAString_internal::Assign(...) (nsTSubstring.cpp:335) by 0x7A725F1: nsAString_internal::Assign(...) (nsTSubstring.cpp:396) by 0x6774881: nsString::nsString(...) (nsTString.h:99) by 0x7A1D970: nsVariant::SetFromAString(...) (nsVariant.cpp:1480) by 0x7A1E647: nsVariant::SetAsAString(...) (nsVariant.cpp:2043) by 0x7A0CD4D: nsHashPropertyBag::SetPropertyAsAString(...) (nsHashPropertyBag.cpp:288) by 0x7A682DC: NS_InvokeByIndex_P (xptcinvoke_x86_64_unix.cpp:195) by 0x73AD83D: XPCWrappedNative::CallMethod(...) (XPCWrappedNative.cpp:2907) by 0x73B915B: XPC_WN_CallMethod(...) (XPCWrappedNativeJSOps.cpp:1553) by 0x7EEEFD8: js::InvokeKernel(...) (jscntxtinlines.h:297) by 0x7F06AAB: js::Interpret(...) (jsinterp.cpp:4002) by 0x7EEECE3: js::RunScript(...) (jsinterp.cpp:584) by 0x7EEF103: js::InvokeKernel(...) (jsinterp.cpp:647) by 0x7E6A8AA: js::Invoke(...) (jsinterp.h:148) bz says this is from the feed processor, and that the allocation may be avoidable, depending on what the JSString looks like. Steps to reproduce: - Create a new profile, and add these feeds to the bookmarks toolbar: http://www.bbc.co.uk/go/rss/int/news/-/news/ http://bishophill.squarespace.com/blog/rss.xml http://www2.politicalbetting.com/index.php/feed/ http://newsrss.bbc.co.uk/rss/sportonline_uk_edition/front_page/rss.xml http://www.spectator.co.uk/coffeehouse/index.txml http://feeds2.feedburner.com/guidofawkes http://www.iaindale.com/feed http://feeds.feedburner.com/arseblognews?format=xml http://noconsensus.wordpress.com/feed/ - Run the browser. That's it. bz, I guess you can set a breakpoint on SetPropertyAsAString and wait until it's hit.
Blocks: 692748
So what I had _thought_ we could do is look at the passed-in JSString in XPConnect and avoid an allocation if it's an external string of type sDOMStringFinalizerIndex (because then we know it wraps a stringbuffer and can just refcount it directly). I have the JSAPI end of that done (something that returns a const jschar* if str is an external string of the right type), but actually figuring out where to plug that into XPCConvert is making my eyes bleed.... and Luke had a better plan for avoiding copying at the JS->XPCOM transition in general, so maybe we should just make this bug dependent on that one.
For reference, the JS->XPCOM string-sharing bug is bug 686989.
Depends on: 686989
Whiteboard: [MemShrink] → [MemShrink:P2]

No action in 9 years, closing.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.