firefox 4beta5candidate1 creates enormous system (likely gfx (directx?) layer related) load on winxp - huge contrast to beta4 (no such woes there)

RESOLVED INCOMPLETE

Status

()

Firefox
General
--
major
RESOLVED INCOMPLETE
8 years ago
7 years ago

People

(Reporter: abittner, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [4b5])

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b5) Gecko/20100101 Firefox/4.0b5
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b5) Gecko/20100101 Firefox/4.0b5

maybe some deep internals have changed, but i just upgraded my previously pretty much normally behaving firefox 4 beta4 to the candidate build1 of beta5 (english winxp, x86, multicore cpu, some ati embedded graphics card (portable machine)) and now whenever i even do just as little as enter this text in this edit field while filing this bug, or simpy raise the firefox windows and hover/move the mouse over the firefox areas or scroll the window or surf some pages or do anything at all, firefox creates huge load (100% core load, aka a single thread creates 100% load arriving at 50% cpu load on dualcore machine) apparently in some drawing/display subroutines on this windows xp machine, while beta4 has not behaved like this.

i think i recall some roadmap towards accelerated directx or similar stuff related rendering things the firefox team wanted to do, though im unsure if winxp/directx9 was also affected or being tackled by the roadmap and plans.

but something has a severe impact on the winxp machine and its load, which is very most likely related to the displaying and drawing of things on screen.

process explorer (sysinternals/msft tool) clearly shows firefox generating a very high percentatage of a red graph within its own load, so the green percentage (non-system load) is most of the time very low.

having already followed the amd-code-analyst howto pages on
https://developer.mozilla.org/Profiling_with_AMD_CodeAnalyst

i tried to narrow down the problem with the beta5 build of firefox4, and codeanalyst reports the firefox.exe usage as follows:

a very high hal.dll (55.75% during these 30second sample cycles of codeanalyst) usage (\windows\system32\hal.dll)
second is xul.dll (total of 21.4% cycles) whose internal subroutine load samples dont really look revealing or suspicious to me

and third and fourth place are the ati (graphics driver) components of this machine with 13.17% and 3.41% cpu cycles (ati2cpag.dll and ati2dvag.dll both is \windows\system32\)

fifth position is mozcrt19.dll with 1.96% cpu cycles within the firefox.exe scope......


there has to be some serious changes in the firefox4 codebase which has been added or activated with the beta5 build, which at least makes firefox4 beta5 pretty much unusable on this ati-graphics card based machine.

Reproducible: Always
(Reporter)

Comment 1

8 years ago
something that i forgot:

the hal.dll usage of firefox.exe process is almost completely being consumed by:

------
CS:EIP     	Symbol + Offset             	64-bit 	Timer samples 	
0x806edf54 	HalpQueryPerformanceCounter 	       	98.59         	

1 function, 12 instructions, Total: 8794 samples, 92.61% of samples in the module, 22.03% of total session samples
--------------



and inside that routine apparently by:


---------
CS:EIP     	Symbol + Offset                	64-bit 	Timer samples 	
0x806edf73 	HalpQueryPerformanceCounter+31 	       	97.85         	

1 function, 1 instruction, Total: 8728 samples, 91.91% of samples in the module, 21.87% of total session samples
---------------------

maybe that helps. somebody forgot to turn off some performance counters or something?

cheers.
(Reporter)

Updated

8 years ago
Whiteboard: [4b5]
abittner: Hardware accleration is on by default in this build - see https://wiki.mozilla.org/Platform/2010-08-31#GFX. What happens if you pref it off in your case?
(Reporter)

Comment 3

8 years ago
odd thing is:

that about:config

says those two lines for layers/acceleration
layers.accelerate-all;false
layers.accelerate-none;false

are both set to default boolean false.

is this correct? sound like i dont have acceleration enabled at all, have i?

what do i need to set?
(Reporter)

Comment 4

8 years ago
are we going anywhere? 

i think i need to revert back to firefox4beta4 as beta5 is painstakingly slow and barely usable with this bug.


i hope that im not the sole winxp/ati/ffx4b5 user experiencing this problem or rather wondering if there are other people experiencing this bug.

regards.
abittner: So only Win7 and Vista are supported for hardware acceleration. If you type about:support and scroll down, you should see both Direct2DEnabled and DirectWrite set to false.
(Reporter)

Comment 6

8 years ago
about:support direct2 shows as false.

Graphics
Adapter DescriptionATI Radeon Xpress Series Vendor ID1002Device ID5975Adapter RAMUnknownAdapter Driversati2dvagDriver Version8.591.0.0Driver Date2-25-2009Direct2D EnabledfalseDirectWrite Enabledfalse



so why is this such a huge loss of responsiveness and such an increase of hal.dll workload?

what has changed with beta5 regarding winxp? like i wrote before, my knowledge was that these directx/directd methods were only being considered and being added for vista and higher win operating systems.

so why is there any impact at all on winxp?

anyone seen any other related bugs to mine? 
i wonder if others find ffx4beta5 unusable on winxp similar to me.

:( regards.
(Reporter)

Comment 7

8 years ago
even with -safe-mode and selecting disable all addons firefox behaves like this all the time.

hal.dll is running mad and generating 98%-99%
CS:EIP     	Symbol + Offset             	64-bit 	Timer samples 	
0x806edf54 	HalpQueryPerformanceCounter 	       	98.45         	

1 function, 7 instructions, Total: 3611 samples, 86.97% of samples in the module, 18.09% of total session samples

load......... (percentage inside hal.dll load)

resulting in firefox roughly using 4x%-50% cpu on a dualcore machine, meaning this hal.dll load consuming a complete core for itself :((
(Reporter)

Comment 8

8 years ago
reverted back to ffx4beta4 and doublechecked there:


using this bugzilla bugreport website with this textbox/comments area as my benchmark....

typing some random text in here, and check-spelling activated for this textbox the beta4 results within firefox.exe load are as follows:

Process Name 	64-bit 	Timer samples 	
xul.dll      	       	66.09         	
MOZCRT19.dll 	       	9.76          	
hal.dll      	       	8.72          	
ntkrnlpa.exe 	       	4.16          	
ntdll.dll    	       	2.37          	
win32k.sys   	       	2.14          	
nspr4.dll    	       	1.91          	
ati2cqag.dll 	       	1.1           	
USER32.dll   	       	0.69          	
kernel32.dll 	       	0.58          	
ati2dvag.dll 	       	0.52          	
MSCTF.dll    	       	0.46          	
GDI32.dll    	       	0.35          	


---------

the percentage of the load being consumed for hal.dll functions is way lower than with beta5.

something is wrong here.

:(

Comment 9

8 years ago
I just updated to the "official" beta 5 on a WinXP machine and am seeing 90-100% CPU usage if I do anything at all in Firefox, including typing this comment. (I haven't done all the testing abittner has, other than checking about:config and about:support as mentioned above, and all are "false.")  

I agree - something is wrong. :(
(Reporter)

Comment 10

8 years ago
phew, thanks for that comment, i was already scared that i had some exotic system, drivers or system specs here that would leave me alone with this bug ;(

the only system i had for testing this situation so far is some older business laptop from hp/compaq with integrated ati chipset, and the latest catalyst driver for winxp was the 10.2 catlyst, meaning february 2010 as a release date, and just as of very recently some days ago ati/amd hinted that they wouldnt be releasing any newer catlyst drivers any more for their older chipsets, although they had planned to do so before.

well anyways, maybe its not even an ati/drivers problem as older firefox builds (even earlier ffx4 betas) worked just fine, ofcourse i understand that probably new drawing subsystems have been established and are being used, only i fail to understand why this would affect the winxp platform, as my understanding was that these new direct2d/direct3d things were only being activated in firefox4 for vista and higher windows operating systems using directx10 and so on......


i will try to find some other systems with winxp where i can mess around with ffx4 beta4/beta5 and try to verify there, but i have no eta/timeframe for that.

thanks and regards.
(Reporter)

Comment 11

8 years ago
so i am here on a completely different machine using windows xp as well and using firefox 4 beta4 build for starters, later comparing beta5 results....


the above text was just my benchmark inside this comment window .... on this other machine i found.


system:
windows xp professional, sp3, x86, firefox 3.6.x so far, longterm usage of firefox (profile wise).

added firefox 4 beta4 as an additional browser. started up firefox4 beta4 and now i am here.


hardware is embedded (onboard, desktop machine) ati chipset, ati radeon hd 4200 / rs880 / 785G onboard integrade gpu chipset

latest (august 2010, radeon catalyst 10.8 drivers package being used).


the amd code analyst results for beta4 (typing in this comments box) for starters:

whole firefox.exe process load on this quad/4 core machine:
Process Name 	64-bit 	Timer samples 	
firefox.exe  	       	2.46          	


load within firefox.exe process:
Process Name 	64-bit 	Timer samples 	
xul.dll      	       	63.8          	
MOZCRT19.dll 	       	8.9           	
hal.dll      	       	5.8           	
ntkrnlpa.exe 	       	5.64          	
win32k.sys   	       	4.68          	
ntdll.dll    	       	3.41          	
nspr4.dll    	       	1.83          	
USER32.dll   	       	1.37          	
kernel32.dll 	       	0.86          	
ati2dvag.dll 	       	0.71          	
ati2cqag.dll 	       	0.66          	


-------

hal.dll has fairly low percentage, xul.dll is largest.

will test beta5 after this.
(Reporter)

Comment 12

8 years ago
beta5:

firefox4 beta5 results are not as bad as on the other machine (business laptop) here on this one, still the whole firefox gui/ui feels somehow still a bit more lagging, less responsive and dragging, even on this much newer chipset/machine and twice as much cores.

so take the cpu and load percentages with a grain of salt, maybe multiplying by factor two isnt just enough or an aproach too simple and results might probably not be that comparable.

also ofcourse the whole ati/amd driver is much newer and most current, whereas the driver for the business laptop chipset is way older.

typing in this comment textbox (spellchecking turned off) benchmark:

Process Name 	64-bit 	Timer samples 	
firefox.exe  	       	3.49          	

within firefox.exe process:
Process Name 	64-bit 	Timer samples 	
xul.dll      	       	61.56         	
hal.dll      	       	16.89         	
MOZCRT19.dll 	       	6.42          	
win32k.sys   	       	3.84          	
ntkrnlpa.exe 	       	3.26          	
ntdll.dll    	       	3.05          	
nspr4.dll    	       	1.11          	
ati2dvag.dll 	       	0.68          	
ati2cqag.dll 	       	0.61          	


-------

so hal.dll still accounts for almost 17% cpu usage (remember the 4 cores on this machine).

inside hal.dll:
CS:EIP     	Symbol + Offset                	64-bit 	Timer samples 	
0x806ecf73 	HalpQueryPerformanceCounter+31 	       	87.05         	
0x806ecf58 	HalpQueryPerformanceCounter+4  	       	0.42          	
0x806ecf5e 	HalpQueryPerformanceCounter+10 	       	0.42          	
0x806ecf79 	HalpQueryPerformanceCounter+37 	       	0.42          	
0x806ecf83 	HalpQueryPerformanceCounter+47 	       	0.21          	
0x806ecf85 	HalpQueryPerformanceCounter+49 	       	0.21          	
0x806ecf8c 	HalpQueryPerformanceCounter+56 	       	0.21          	
0x806ecf93 	HalpQueryPerformanceCounter+63 	       	0.21          	
0x806ecf95 	HalpQueryPerformanceCounter+65 	       	0.21          	
0x806ecf54 	HalpQueryPerformanceCounter    	       	89.38         	
0x806e6aa8 	KeReleaseQueuedSpinLock        	       	3.61          	
0x806e69f0 	KeAcquireInStackQueuedSpinLock 	       	2.12          	

3 functions, 16 instructions, Total: 448 samples, 60.79% of samples in the module, 0.56% of total session samples

inside xul.dll:
CS:EIP     	Symbol + Offset                                                     	64-bit 	Timer samples 	
0x101d8840 	mozilla::`anonymous namespace'::ContainerState::ProcessDisplayItems 	       	7.34          	
0x101a7930 	XPCConvert::NativeInterface2JSObject                                	       	4.78          	
0x101d5c30 	nsIFrame::BuildDisplayListForChild                                  	       	3.49          	
0x101bce90 	js::Interpret                                                       	       	2.85          	
0x101daf40 	SearchTable                                                         	       	2.68          	
0x10130c80 	write_string                                                        	       	1.81          	
0x101d6cb0 	nsBoxFrame::BuildDisplayList                                        	       	1.75          	

7 functions, 237 instructions, Total: 424 samples, 24.69% of samples in the module, 0.53% of total session samples
--------

about:support on this quadcore ati radeon hd4200 machine:
gfx section:

Graphics
Adapter Description
ATI Radeon HD 4200
Vendor ID1002
Device ID9710
Adapter RAM Unknown
Adapter Drivers ati2dvag
Driver Version 8.762.0.0
Driver Date 8-3-2010
Direct2D Enabled false
DirectWrite Enabled false

-------------


i would really like to know what happend in terms of drawing the actual pixels or organising the layers elements and objects of the webpages in between the beta4 and beta5 build.

there must have been some severe changes other than that i cant come up with any idea why beta5 would behave so laggy and sluggish in contrast to beta4.

will try some grafx-bot benchmark stuff later on on both machines and both beta versions
https://addons.mozilla.org/en-US/firefox/addon/200733/
(Reporter)

Comment 13

8 years ago
once more for doublecheck.

on the newer winxp/atihd4200 machine, with firefox4 beta4, typing in this comments box, spellcheck off:

firefox complete process load:
Process Name 	64-bit 	Timer samples 	
firefox.exe  	       	1.84          	

within firefox.exe:
Process Name 	64-bit 	Timer samples 	
xul.dll      	       	69.61         	
MOZCRT19.dll 	       	8.5           	
win32k.sys   	       	5.03          	
ntkrnlpa.exe 	       	4.89          	
ntdll.dll    	       	3.74          	
hal.dll      	       	1.9           	
nspr4.dll    	       	1.43          	
USER32.dll   	       	1.22          	
kernel32.dll 	       	0.82          	
ati2cqag.dll 	       	0.48          	
GDI32.dll    	       	0.48          	


very low hal.dll load all the times, have tried to bench this repeatedly. hal.dll load is always low/normal.

---
Application Basics
Name Firefox
Version 4.0b4

Graphics Direct2D Enabled false
----
(Reporter)

Comment 14

8 years ago
maybe some more hints.

the faser hd4200 based machine:
grafx-bot results:

beta4:
http://brasstacks.mozilla.com/resultserv/data/results/fc145ac8-4613-43c2-9f7c-6c41bd1ece57

beta5:
http://brasstacks.mozilla.com/resultserv/data/results/3930325c-9901-4002-964b-0b04885fc544


more tests fail in beta5 than in beta4.

beta4 finishes the grafx bot tests a whole lot quicker than beta5.
(Reporter)

Comment 15

8 years ago
on the other slower machine (hp compaq business laptop), grafx-bot results:

beta4: (almost all tests pass, except for one)
http://brasstacks.mozilla.com/resultserv/data/results/20e275b2-3df4-4e5d-8172-599276994965

beta5: (more tests fail here)
http://brasstacks.mozilla.com/resultserv/data/results/f0779ce5-c928-452f-bfa0-81434cc0e49c
(Reporter)

Comment 16

8 years ago
update with more recent firefox 4 beta7 pre (minefield) builds.

have been using beta7 pre builds for the past one or two weeks in addition to the release betaX builds of firefox 4.


this bug behaviour changes almost daily in the b7pre builds. some daily builds are really fast, lowlatency and well behaving, others feature sometimes almost constant 50% cpu (aka 1full core) loads on a dualcore machine.

for example with build:
Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100926 Firefox/4.0b7pre

its really bad today. minefiled (firefox.exe) is really lagging a lot:
amd codeanalyst displays again large hal.dll load and xul load.

hal.dll load:
CS:EIP     	Symbol + Offset             	64-bit 	Timer samples 	
0x806edf54 	HalpQueryPerformanceCounter 	       	97.05         	

1 function, 10 instructions, Total: 2531 samples, 88.68% of samples in the module, 12.68% of total session samples

-----

xul.dll load:
exibits mainly various javascript related(?) load:

CS:EIP     	Symbol + Offset                                                     	64-bit 	Timer samples 	
0x1023da60 	JSCompartment::purge                                                	       	8.08          	
0x101b4dc0 	mozilla::`anonymous namespace'::ContainerState::ProcessDisplayItems 	       	4.78          	
0x1019dd80 	JS_TraceChildren                                                    	       	3.99          	
0x1023d850 	JSC::RepatchBuffer::relink                                          	       	3.29          	
0x102eee40 	js::PurgeScriptFragments                                            	       	3.03          	
0x101b7490 	PL_DHashTableOperate                                                	       	2.55          	
0x101b3bc0 	nsIFrame::BuildDisplayListForChild                                  	       	2.5           	
0x1023da10 	js::Vector<JSC::ExecutablePool *,0,js::SystemAllocPolicy>::end      	       	2.34          	
0x10169aa0 	nsPresContext::GetRootPresContext                                   	       	1.91          	
0x102eed30 	js_DestroyScript                                                    	       	1.75          	
0x101b7720 	SearchTable                                                         	       	1.59          	
0x1023d8f0 	js::mjit::ic::PurgePICs                                             	       	1.54          	
0x1019d8b0 	fun_trace                                                           	       	1.38          	
0x101b3b10 	nsStyleContext::DoGetStyleDisplay                                   	       	1.38          	
0x1023d870 	GetPropCompiler::reset                                              	       	1.28          	
0x101b3ac0 	nsRuleNode::GetStyleDisplay                                         	       	1.22          	
0x101ae220 	nsBoxFrame::BuildDisplayList                                        	       	1.17          	
0x1023d970 	js::mjit::ic::PICInfo::reset                                        	       	1.06          	

18 functions, 279 instructions, Total: 844 samples, 44.85% of samples in the module, 4.23% of total session samples
------------

:((
anyone care for this bug? why is the hal.dll stuff so flaky, one day the build suffers from huge hal.dll load, the next day the following build is back to virtually normal behaviour.

the javascript stuff might be related to some other code areas and bugs i guess and not necessarily directly related
maybe this
https://bugzilla.mozilla.org/show_bug.cgi?id=579653
and
https://bugzilla.mozilla.org/show_bug.cgi?id=570435
.....

cheers.
(Reporter)

Comment 17

8 years ago
summing up the past few days worth of nightlies of beta7pre:

every day a new/different situation. one nightly is pretty nice, reactive, doesnt show this hal.dll load problem too much, the next day the following nightly build is all messy again, huge hal.dll/halpqueryperformancecounter load once again.

its really hard this way and i just havent found any place on the web or on the vast amount of mozilla pages blogs and development areas to be able to find out about these directx/layer/d3d/d2d and whatnoth features, and i still generally fail to understand why we/i actually see any problems using a windowsxp operating system, because so far any reliable information i found, was stating that nothing changes for winxp users (which simply cannot be true according to my experience and findings, this is obvious by now) but only for vista/win7/directx10+ users upwards.

so todays build:
Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20101006 Firefox/4.0b7pre
Source Built from http://hg.mozilla.org/mozilla-central/rev/dee1e01fd8ed

is one of the slower daily builds of the recent week or so, not the worst/slowest though, and i dont have any of the recently experienced mozalloc.dll crashes (sadly unhandled by breakpad/crashreporter :((( ) as i posted in my other bug at https://bugzilla.mozilla.org/show_bug.cgi?id=600481

i re-started with multiple windows tabs and tabcandy/panorama and waited a while to find a somewhat idle state of the firefox.exe process and measured with amd-codeanalst:

idle firefox (on avarage still using 11%cpu)
Process Name 	64-bit 	Timer samples 	
firefox.exe  	       	11.18         	

within firefox.exe:
Process Name 	64-bit 	Timer samples 	
xul.dll      	       	36.99         	
hal.dll      	       	30.28         	
mozjs.dll    	       	16.23         	
MOZCRT19.dll 	       	5.56          	
win32k.sys   	       	2.6           	
ntdll.dll    	       	2.02          	
ntkrnlpa.exe 	       	1.66          	
ati2cqag.dll 	       	1.55          	
nspr4.dll    	       	0.58          	
ati2dvag.dll 	       	0.4           	

there you can see some hal.dll load already.

xul.dll load:
CS:EIP     	Symbol + Offset                                                     	64-bit 	Timer samples 	
0x1005e000 	PresShell::DidPaint                                                 	       	7.88          	
0x100b2690 	PL_DHashTableOperate                                                	       	6.36          	
0x1007f110 	nsViewManager::DispatchEvent                                        	       	5.94          	
0x100b2bb0 	mozilla::`anonymous namespace'::ContainerState::ProcessDisplayItems 	       	5.03          	
0x100ba8e0 	nsBoxFrame::BuildDisplayList                                        	       	4             	
0x100b58b0 	nsIFrame::BuildDisplayListForChild                                  	       	2.85          	
0x100b2530 	mozilla::FramePropertyTable::Get                                    	       	2.48          	
0x100b25a0 	SearchTable                                                         	       	2.24          	
0x101f5e60 	GraphWalker<scanVisitor>::DoWalk                                    	       	2.24          	
0x10116e60 	nsViewManager::ProcessPendingUpdates                                	       	1.76          	
0x100f6f20 	ChangeTable                                                         	       	1.64          	
0x100b6df0 	nsRuleNode::GetStyleDisplay                                         	       	1.58          	
0x100b72f0 	NoteJSChild                                                         	       	1.33          	
0x100b6dc0 	nsStyleContext::DoGetStyleDisplay                                   	       	1.21          	
0x1009a0f0 	nsXPConnect::Traverse                                               	       	1.09          	

15 functions, 285 instructions, Total: 786 samples, 47.64% of samples in the module, 1.97% of total session samples

--------

hal.dll load:
CS:EIP     	Symbol + Offset                   	64-bit 	Timer samples 	
0x806edf54 	HalpQueryPerformanceCounter       	       	95.78         	
0x806e5ad0 	HalpReleaseSystemHardwareSpinLock 	       	1.78          	
0x806e79f0 	KeAcquireInStackQueuedSpinLock    	       	0.89          	

3 functions, 13 instructions, Total: 1330 samples, 66.27% of samples in the module, 3.33% of total session samples

----

halpqueryperformance counter as usual behaving badly:
CS:EIP     	Symbol + Offset                	64-bit 	Timer samples 	
0x806edf73 	HalpQueryPerformanceCounter+31 	       	94.52         	
0x806edf93 	HalpQueryPerformanceCounter+63 	       	0.44          	
0x806edf54 	HalpQueryPerformanceCounter+0  	       	0.15          	
0x806edf55 	HalpQueryPerformanceCounter+1  	       	0.15          	
0x806edf79 	HalpQueryPerformanceCounter+37 	       	0.15          	
0x806edf88 	HalpQueryPerformanceCounter+52 	       	0.15          	
0x806edf6c 	HalpQueryPerformanceCounter+24 	       	0.07          	
0x806edf7f 	HalpQueryPerformanceCounter+43 	       	0.07          	
0x806edf83 	HalpQueryPerformanceCounter+47 	       	0.07          	
0x806edf54 	HalpQueryPerformanceCounter    	       	95.78         	

1 function, 9 instructions, Total: 1294 samples, 64.47% of samples in the module, 3.24% of total session samples
----------



so after that i wanted to see if firefox.exe would eat up a whole core again when being nagged a bit of input. so i created one new tab (empty), and simply started to move about the mouse a bit, and all of a sudden firefox.exe went lunatic:


Process Name 	64-bit 	Timer samples 	
firefox.exe  	       	45.71         	
System Idle  	       	40.18         	
System       	       	4.95          	

----


Process Name 	64-bit 	Timer samples 	
hal.dll      	       	47.71         	
ati2dvag.dll 	       	15.85         	
xul.dll      	       	11.05         	
ntkrnlpa.exe 	       	10.61         	
ati2cqag.dll 	       	8.94          	
MOZCRT19.dll 	       	1.93          	
win32k.sys   	       	1.57          	
ntdll.dll    	       	0.47          	

----

CS:EIP     	Symbol + Offset                   	64-bit 	Timer samples 	
0x806edf54 	HalpQueryPerformanceCounter       	       	93.73         	
0x806e7fb0 	HalpPmTimerStallExecProc          	       	3.32          	
0x806e5ad0 	HalpReleaseSystemHardwareSpinLock 	       	1.41          	
0x806e79f0 	KeAcquireInStackQueuedSpinLock    	       	0.44          	

4 functions, 21 instructions, Total: 8611 samples, 90.86% of samples in the module, 21.57% of total session samples

--------

interesting xul.dll load as well:
CS:EIP     	Symbol + Offset                                                     	64-bit 	Timer samples 	
0x1007f110 	nsViewManager::DispatchEvent                                        	       	8.48          	
0x1005e000 	PresShell::DidPaint                                                 	       	8.38          	
0x100b2bb0 	mozilla::`anonymous namespace'::ContainerState::ProcessDisplayItems 	       	7.19          	
0x100ba8e0 	nsBoxFrame::BuildDisplayList                                        	       	4.16          	
0x100b58b0 	nsIFrame::BuildDisplayListForChild                                  	       	4.02          	
0x100b2530 	mozilla::FramePropertyTable::Get                                    	       	2.68          	
0x100b6dc0 	nsStyleContext::DoGetStyleDisplay                                   	       	1.88          	
0x100b6df0 	nsRuleNode::GetStyleDisplay                                         	       	1.88          	
0x100b25a0 	SearchTable                                                         	       	1.74          	
0x100b2690 	PL_DHashTableOperate                                                	       	1.24          	
0x100c5630 	nsTHashtable<nsPtrHashKey<nsIFrame> >::s_EnumStub                   	       	0.94          	
0x100aab10 	nsTArray_base::EnsureCapacity                                       	       	0.89          	
0x100ba4d0 	nsIFrame::GetUsedBorder                                             	       	0.89          	
0x100bb7d0 	mozilla::FrameLayerBuilder::DrawThebesLayer                         	       	0.89          	
0x100d9800 	nsBlockFrame::InvalidateInternal                                    	       	0.79          	
0x100b9680 	nsRegion::SubRect                                                   	       	0.69          	
0x100b8a50 	nsRegion::SetToElements                                             	       	0.64          	
0x100cfd80 	nsIFrame::GetOffsetToCrossDoc                                       	       	0.59          	
0x100d3f50 	nsRuleNode::WalkRuleTree                                            	       	0.59          	
0x1034f54a 	mozilla::FrameLayerBuilder::Clip::Clip                              	       	0.59          	
0x100b84d0 	nsDisplayList::ComputeVisibilityForSublist                          	       	0.55          	
0x100b8b10 	nsRegion::And                                                       	       	0.55          	

22 functions, 410 instructions, Total: 1014 samples, 50.27% of samples in the module, 2.54% of total session samples

-----------



another sampling attempt, while firefox was still going crazy for many minutes:

Process Name 	64-bit 	Timer samples 	
firefox.exe  	       	46.3          	
System Idle  	       	39.34         	
System       	       	5.27          	

----


Process Name 	64-bit 	Timer samples 	
hal.dll      	       	38.02         	
xul.dll      	       	15.42         	
ati2dvag.dll 	       	14.2          	
ntkrnlpa.exe 	       	10.37         	
ati2cqag.dll 	       	7.37          	
mozjs.dll    	       	7.01          	
MOZCRT19.dll 	       	2.91          	
win32k.sys   	       	1.53          	
ntdll.dll    	       	0.75          	
nspr4.dll    	       	0.33          	

-----

xul.dll load:
CS:EIP     	Symbol + Offset                                                     	64-bit 	Timer samples 	
0x1007f110 	nsViewManager::DispatchEvent                                        	       	5.04          	
0x1005e000 	PresShell::DidPaint                                                 	       	4.66          	
0x100ba8e0 	nsBoxFrame::BuildDisplayList                                        	       	3.99          	
0x100b2690 	PL_DHashTableOperate                                                	       	3.96          	
0x100b2bb0 	mozilla::`anonymous namespace'::ContainerState::ProcessDisplayItems 	       	3.92          	
0x100b58b0 	nsIFrame::BuildDisplayListForChild                                  	       	2.42          	
0x100b25a0 	SearchTable                                                         	       	1.54          	
0x100b2530 	mozilla::FramePropertyTable::Get                                    	       	1.51          	
0x101f5e60 	GraphWalker<scanVisitor>::DoWalk                                    	       	1.4           	
0x100b6df0 	nsRuleNode::GetStyleDisplay                                         	       	1.26          	
0x100b72f0 	NoteJSChild                                                         	       	1.19          	
0x100b6dc0 	nsStyleContext::DoGetStyleDisplay                                   	       	1.02          	
0x100a3530 	XPC_WN_GetterSetter                                                 	       	0.95          	
0x100f6f20 	ChangeTable                                                         	       	0.84          	
0x100a7060 	nsXPCWrappedJSClass::CallMethod                                     	       	0.81          	
0x100cfd80 	nsIFrame::GetOffsetToCrossDoc                                       	       	0.74          	
0x100a21e0 	XPCConvert::NativeInterface2JSObject                                	       	0.7           	

17 functions, 386 instructions, Total: 1026 samples, 35.91% of samples in the module, 2.56% of total session samples

Updated

7 years ago
Version: unspecified → Trunk

Comment 18

7 years ago
Reporter -> Are you still experiencing this issue with the latest version of Firefox 5? Does the issue occur with the latest nightly? http://nightly.mozilla.org/

Comment 19

7 years ago
Closing bug as Incomplete - if you are still experiencing this issue or have more information to provide feel free to post back here and we can re-open the bug. You can also get assistance by visiting the Firefox help site -> http://support.mozilla.com/en-US/kb/Ask+a+question
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.