[cycle collector] freeze/pause after clicking on a link?

RESOLVED FIXED

Status

()

RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: moco, Unassigned)

Tracking

Trunk
x86
All
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

[places] brief freeze/pause after clicking on a link?

I'm not sure what's going on, but I'm running a places bookmarks build (with the bookmarks sidebar open, in case that matters), and for a while I think I've noticed a brief freeze/pause after I click on links.

nothing more yet, but I'll keep an eye out.

but my gut tells me it is places.
I'm frequently seeing about a 40% cpu usage on my debug windows trunk build.

graydon, could this be the culprit?

 	ntdll.dll!7c918893() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
 	ntdll.dll!7c918238() 	
 	ntdll.dll!7c911c76() 	
 	ntdll.dll!7c91825d() 	
 	ntdll.dll!7c912270() 	
 	ntdll.dll!7c911596() 	
 	ntdll.dll!7c9106eb() 	
 	ntdll.dll!7c911538() 	
 	ntdll.dll!7c911596() 	
 	ntdll.dll!7c910e91() 	
 	ntdll.dll!7c9106eb() 	
>	msvcr80d.dll!_heap_alloc_base(unsigned int size=1083)  Line 105 + 0x28 bytes	C
 	msvcr80d.dll!_heap_alloc_dbg(unsigned int nSize=1047, int nBlockUse=1, const char * szFileName=0x00000000, int nLine=0)  Line 409 + 0x9 bytes	C++
 	msvcr80d.dll!_nh_malloc_dbg(unsigned int nSize=1047, int nhFlag=0, int nBlockUse=1, const char * szFileName=0x00000000, int nLine=0)  Line 266 + 0x15 bytes	C++
 	msvcr80d.dll!malloc(unsigned int nSize=1047)  Line 152 + 0x15 bytes	C++
 	js3250.dll!JS_ArenaAllocate(JSArenaPool * pool=0x021ed9c8, unsigned int nb=16)  Line 158 + 0xa bytes	C
 	js3250.dll!SprintAlloc(Sprinter * sp=0x0012f1a8, unsigned int nb=9)  Line 374 + 0x5a bytes	C
 	js3250.dll!QuoteString(Sprinter * sp=0x0012f1a8, JSString * str=0x00d4da30, unsigned long quote=0)  Line 503 + 0x13 bytes	C
 	js3250.dll!js_QuoteString(JSContext * cx=0x021ed978, JSString * str=0x00d4da30, unsigned short quote=0)  Line 576 + 0x12 bytes	C
 	js3250.dll!js_ValueToPrintable(JSContext * cx=0x021ed978, long v=13949492, JSString * (JSContext *, long)* v2sfun=0x004718bb)  Line 2640 + 0xf bytes	C
 	js3250.dll!js_AtomToPrintableString(JSContext * cx=0x021ed978, JSAtom * atom=0x00d51d18)  Line 63 + 0x15 bytes	C
 	xpc3250.dll!nsXPConnect::Traverse(void * p=0x03f17200, nsCycleCollectionTraversalCallback & cb={...})  Line 688 + 0x19 bytes	C++
 	xpcom_core.dll!GraphWalker::NoteScriptChild(unsigned int langID=2, void * child=0x03f17200)  Line 770	C++
 	xpc3250.dll!nsXPConnect::Traverse(void * p=0x03f171a0, nsCycleCollectionTraversalCallback & cb={...})  Line 769	C++
 	xpcom_core.dll!GraphWalker::Walk(void * s0=0x3fafbdf0)  Line 802 + 0x30 bytes	C++
 	xpcom_core.dll!nsCycleCollector::MarkRoots()  Line 859 + 0x21 bytes	C++
 	xpcom_core.dll!nsCycleCollector::Collect(unsigned int aTryCollections=1)  Line 1678	C++
 	xpcom_core.dll!nsCycleCollector_collect()  Line 1912	C++
 	gklayout.dll!nsJSContext::Notify(nsITimer * timer=0x3e6ba240)  Line 3177	C++
 	xpcom_core.dll!nsTimerImpl::Fire()  Line 387	C++
 	xpcom_core.dll!nsTimerEvent::Run()  Line 458	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0012f68c)  Line 483	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00b9c520, int mayWait=1)  Line 225 + 0x16 bytes	C++
 	gkwidget.dll!nsBaseAppShell::Run()  Line 154 + 0xc bytes	C++
 	tkitcmps.dll!nsAppStartup::Run()  Line 171 + 0x1c bytes	C++
 	xul.dll!XRE_main(int argc=1, char * * argv=0x00b997d8, const nsXREAppData * aAppData=0x004036b4)  Line 2860 + 0x25 bytes	C++
 	firefox.exe!main(int argc=1, char * * argv=0x00b997d8)  Line 61 + 0x13 bytes	C++
 	firefox.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes	C
 	firefox.exe!mainCRTStartup()  Line 403	C
 	kernel32.dll!7c816fd7() 	
 	ntdll.dll!7c91056d() 	
Yes. See this thread:
http://groups.google.ca/group/mozilla.dev.performance/browse_thread/thread/e85e4111fe1b9782

The short summary is that there's a lot of debug code in the cycle collector, so when you run a debug build it gets a lot slower. There's also a lot of "safety" code that's not #ifdef DEBUG. So we can degrade the safety code to #ifdef DEBUG and/or some of the #ifdef DEBUG code to simply not be built at all, depending on how slow it feels. 
Status: NEW → ASSIGNED
graydon, thanks for link to dbaron's post.  (I'm relieved this performance issue isn't places related, and it was known.)

for me, on my 1.6 Ghz / 2GB Windows XP laptop, it makes the debug browser pretty slow.  Nearly unusable at times. 

note, this is my debug build, so #ifdef DEBUG isn't going to help me, so perhaps we could do #ifdef DEBUG_XPCOM_CYCLE_COLLECTOR or something else?
Summary: [places] brief freeze/pause after clicking on a link? → [cycle collector] freeze/pause after clicking on a link?
Status: ASSIGNED → NEW
Component: Places → XPConnect
OS: Windows XP → All
Product: Firefox → Core
QA Contact: places → xpconnect
Version: 2.0 Branch → Trunk
this should be affecting scott and david when debugging the trunk tbird builds, too.
Peter, should we take something like that patch (perhaps without "graydon" in it and some DEBUG_username stuff to define the relevant macro for people who care)?
I've been using DEBUG_CC (see patch in bug 373693). I'm fine with ifdef'ing this.
Comment on attachment 260066 [details] [diff] [review]
patch per graydon

I'll land this tomorrow with ifdef DEBUG_CC
Attachment #260066 - Flags: superreview+
Attachment #260066 - Flags: review+
Checked that patch in, let's file remaining issues as separate bugs.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Updated

12 years ago
Flags: in-testsuite-

Comment 11

11 years ago
Please take a look at

http://www.heise.de/security/news/foren/go.shtml?forum_id=118386&list=1&hs=0&e=all

Any of the following actions performed on a link

b) left click
a) right click
c) middle click

seem to freeze firefox for about one second. Within that time nothing else is
updated and you cannot switch tabs.

System: Lx i386, FF 1.5.0.12, javascript off.
Workaround: disable style sheets

A different forum does not show this behavior:

http://www.heise.de/newsticker/foren/go.shtml?forum_id=118441&list=1&hs=0&e=all

Any suggestions?
This bug is related to a regression for a feature which exists only on the Gecko 1.9 trunk (what will become Firefox 3.0). Whatever issue you're having with 1.5.0.12 is completely unrelated to this bug. Please file a new bug for it.
You need to log in before you can comment on or make changes to this bug.