Closed Bug 143303 Opened 24 years ago Closed 20 years ago

Camino uses 50% cpu when in background should be zero (after downloads)

Categories

(Camino Graveyard :: General, defect, P2)

Product:
Camino Graveyard
Component:
General
Platform:
PowerPC
macOS
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME
Milestone:
Camino1.0

People

(Reporter: mcafee, Assigned: sfraser_bugs)

Details

(Keywords: embed)

Chimera uses 50% cpu when in background should be zero. top -au sample Netscape 10 -> [salica3:homes/legolas/csalinas] root# sample Navigator 10 10 Sample analysis of process 646 written to file /tmp/Navigator_646.sample.txt [salica3:homes/legolas/csalinas] root# more /tmp/Navigator_646.sample.txt Analysis of sampling pid 646 every 10 milliseconds Call graph: 1000 Thread_3d03 1000 start 1000 _start 1000 NSApplicationMain 1000 -[NSApplication run] 1000 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 1000 _DPSNextEvent 1000 BlockUntilNextEventMatchingListInMode 1000 ReceiveNextEventCommon 1000 RunCurrentEventLoopInMode 1000 CFRunLoopRunSpecific 1000 __CFRunLoopRun 978 mach_msg 978 mach_msg_trap 978 mach_msg_trap [STACK TOP] 12 __CFRunLoopDoTimer 10 __NSFireTimer 6 -[EventQueueHandler eventTimer:] 4 nsEventQueueServiceImpl::GetThreadEventQueue(PRThread *, nsIEventQueue **) 2 nsCOMPtr_base::assign_from_helper(nsCOMPtr_helper const &, nsID const &) 2 nsQueryInterface::operator()(nsID const &, void **) const 2 nsEventQueueImpl::QueryInterface(nsID const &, void **) 1 GetIID__13nsIEventQueue_nsIEventQueue_h_8s65ni 1 GetIID__13nsIEventQueue_nsIEventQueue_h_8s65ni [STACK TOP] 1 nsEventQueueImpl::QueryInterface(nsID const &, void **) [STACK TOP] 1 PR_EnterMonitor 1 pthread_self 1 pthread_self [STACK TOP] 1 PR_ExitMonitor 1 PR_Unlock 1 pthread_self 1 pthread_self [STACK TOP] 1 Repeater::DoRepeaters(EventRecord const &) 1 Repeater::DoRepeaters(EventRecord const &) [STACK TOP] 1 nsEventQueueImpl::PendingEvents(int *) 1 PL_EventAvailable 1 PR_EnterMonitor 1 PR_EnterMonitor [STACK TOP] 1 NSPopAutoreleasePool 1 NSFoundationVersionString 1 NSFoundationVersionString 1 NSFoundationVersionString [STACK TOP] 1 NSPushAutoreleasePool 1 _NSCurrentThread 1 NSFoundationVersionString 1 NSFoundationVersionString [STACK TOP] 1 _NSRemoveHandler2 1 _NSRemoveHandler2 [STACK TOP] 1 nsEventQueueImpl::PendingEvents(int *) 1 nsEventQueueImpl::PendingEvents(int *) [STACK TOP] 2 __CFRunLoopTimerRescheduleWithAllModes 2 mk_timer_arm 2 mk_timer_arm [STACK TOP] 7 __CFRunLoopDoObservers 5 __CFArrayInit 5 _CFRuntimeCreateInstance 3 CFAllocatorAllocate 3 malloc_zone_malloc 2 szone_malloc 2 small_malloc_should_clear 2 small_malloc_from_free_list 1 _spin_lock_try 1 _spin_lock_try [STACK TOP] 1 kUNCTextFieldValuesKey 1 kUNCTextFieldValuesKey [STACK TOP] 1 malloc_zone_malloc [STACK TOP] 1 _CFRuntimeCreateInstance 1 _CFRuntimeCreateInstance [STACK TOP] 1 malloc_zone_malloc 1 malloc_zone_malloc [STACK TOP] 1 CFRelease 1 CFRelease [STACK TOP] 1 CFSetApplyFunction 1 CFSetApplyFunction [STACK TOP] 1 __CFRunLoopModeFindTimerForMachPort 1 spin_unlock 1 spin_unlock [STACK TOP] 1 _spin_lock_try 1 _spin_lock_try [STACK TOP] 1 kCFCoreFoundationVersionString 1 kCFCoreFoundationVersionString [STACK TOP] 1000 Thread_3e03 1000 _pthread_body 1000 forkThreadForFunction 1000 pthread_exit 1000 mach_msg 1000 mach_msg_trap 1000 mach_msg_trap [STACK TOP]
-> hyatt what page are you looking at? does it have a lot of animated gifs, or about:blank?
Assignee: saari → hyatt
just about:blank. A friend works in apple perf group, that was his first minus mark for chimera. "This is in the background, it should be zero cpu". Looks like event stuff, are we missing nspr threading optimization for OSX?
URL: about:blank
i'll take this. looks like we need to copy win/linux and post the plevent to the native event queue when _pl_NativeNotify is called. cc'ing conrad since he did some of this poking around for the CFM build
Assignee: hyatt → pinkerton
Component: Browser-General → XP Toolkit/Widgets
Keywords: embed
Priority: -- → P2
Target Milestone: --- → mozilla1.0.1
So this doesn't always happen. It happens once in a while. Like right now, it's at 0.8% in the background, but i've seen it at 98% just sitting still. We use a bunch, and then over time, slowly go back down to nothing. However, that time is like 2 minutes of just sitting there doing nothing. Why on earth does it take so long to settle down? Perhaps our timer code is really really freaked out. i think your friend is over-reacting, but i'll keep looking.
Status: NEW → ASSIGNED
the more i try to repro this, the more i just see us sitting at 0% cpu when nothing is happening. ok, maybe 0.8% because the caret is flashing. this certainly isn't something that happens all the time. *shrug*
pink: yes, this was just an at-first-glance-this-looks-wrong reaction. If things settle, ok, but I figured file a bug and take a look.
Is this bug specific to Chimera, or is it about Fizzilla in general? Also, is there a separate RFE bug asking to eliminate all CPU usage when Fizzilla is backgrounded and/or has no open windows? Currently it steals a couple percent while doing nothing. I know that MSIE and various other apps are just as guilty of this, but it's still worth fixing eventually.
bryner said he'd start taking a look at ways to get rid of the timer in nsToolkit.
Assignee: pinkerton → bryner
Status: ASSIGNED → NEW
I've seen times when Chimera uses 98% of the CPU after launch, and the only way to 'fix' it is to quit and relaunch. IIRC, profiling showed the necko threads doing stuff like DNS. However, most of the time, CPU usage is really low. I'm not sure that the NSTimer accounts for much at all.
Is this bug still reveleant ? Could the subject be updated, it's Camino nowdays ...
Chimera -> Camino resummary
Summary: Chimera uses 50% cpu when in background should be zero → Camino uses 50% cpu when in background should be zero
We're using CFRunLoop stuff for plevents now, and high CPU usage issues seem to be fixed.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
sorry simon, i still see it on my laptop with 09a1. samples show little of use, besides maybe some action drawing progress indicators (when none are visible). sometimes it goes away if you leave it, other times it doesn't. trust me, this isn't fixed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Back to Camino where it should be.
Component: XP Toolkit/Widgets → General
Product: Core → Camino
Target Milestone: mozilla1.0.1 → Camino1.0
Version: Trunk → unspecified
We're leaking download view stuff, which entrains progress indicators. Taking.
Assignee: bryner → sfraser_bugs
URL: about:blank
Status: REOPENED → NEW
Summary: Camino uses 50% cpu when in background should be zero → Camino uses 50% cpu when in background should be zero (after downloads)
Target Milestone: Camino1.0 → Camino0.9
(In reply to comment #15) > We're leaking download view stuff, which entrains progress indicators. Taking. Do you mean bug 293995?
(In reply to comment #16) > (In reply to comment #15) > > We're leaking download view stuff, which entrains progress indicators. Taking. > > Do you mean bug 293995? That's not a leak, just a timer issue. I looked in more detail, and actually we're not download views. I see a single leaked NSProgressIndicator (irrespective of how many downloads are done); the extra retain appears to come from the threaded animation code, so I'll turn that off for now.
Status: NEW → ASSIGNED
Target Milestone: Camino0.9 → Camino1.0
Whats the status of this, I fixed a few things in the download manager since the checkin of persistent downloads, (bug 187619 && bug 293995). Is this still an issue, and if it is, are we still pinging around 50%?
Flags: camino1.0?
Can some one please test this for me as well, is it a 10.3 only issue or does the problem exist on cross-OS versions?
Marking WFM.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → WORKSFORME
Clearing ? flag on closed bug.
Flags: camino1.0?
WFW, latest trunk build on 10.4.4 Marked "Verified"
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.