If you go to http://www.blue-c.com/local/index_html?http://www.blue- c.com/local/Leistungen/index_htmlx_Y_xfile=0 and move the mouse over 'Projekt Management' - cpu pegs to 100% and the animation very slow. Tested with build 2002042403 and the reflow-branch build (bug 129115) 2002042219 on win-xp,1.1ghz,512RAM Seems this is related to http://bugzilla.mozilla.org/show_bug.cgi?id=107746#c36 and #37. (In this regard http://bugzilla.mozilla.org/show_bug.cgi?id=87808#c17 iss also interesting).

Instead of creating lots of bugs with different testcases for DHTML performance issues, I think it would be more helpful to have a single Web site where the test cases can be organized. Right now we have so many bugs and testcases that I'm losing track of what the issues are. Markus, that might be a better use of your time (which is MUCH appreciated!)

Changing QA Contact

Looks like we mostly reflow tables all over....

We spend all the time in reflow; most of it in reflowing dirty lines that are absolute frames enclosing inline frames of text. Probably a combination of bug 129115 and the bug about optmizing reposition of absolute frames.

Robert, see http://bugzilla.mozilla.org/show_bug.cgi?id=140789 . That bug is about one big test. Greets

http://www.world-direct.com/mozilla/columniosity Performs strange on Moz 1.0 Trunk Build 2002061908: After being initialized, the animation chnages frames only every few seconds for a few times, then, all of a sudden, it would start to performs totally smoothly. On 1.0 2002053012, it would start the animation at once, but the animation is not very smooth; it's a lot smoother on MSIE 5.5. ALl of these tests have been done on a 1 GHz machine with Win2k. Is this a bug or a feature, does the trunk build probably do some pre- calculating or synchronizing?

The URL in comment 6 totally freezes Mozilla build 20020620 on Windows 2000, Pentium III, 500 Mhz.

For real "hardcore testers" there is the fullscreen version available at http://www.world-direct.com/mozilla/columniosity/index_fullscreen.html

Testing on a 1.1ghz, win2k workstation Mozilla (trunk build 2002062204) completely hangs.

in view of comment #6 this could also be related to bug 157144.

Moving "windows" on the main page of http://www.dhtmlcentral.com is a thousand times slower in Mozilla (2002070904) than in IE 5.5. Menus are slow too but acceptable. This page is probably a very good testing case.

it's not related. While on dhtmlcentral.com windows moves _alomst_ smoothly, we're still blocked with this bug.

waterson doesn't hack on Mozilla any longer, and drivers will not hold 1.3b up for this bug. The way to get joy soon is to find an assignee who will actually hack up a patch for it. Then reviewers can check the patch's intrinsic worth, and whether it's better to wait for 1.4alpha, or it is safe enough for 1.3beta. /be

reassign

Nice progress is made in bug 157681 - maybe this one can be fixed hand in hand, or by minor updates?

Can we get a profile (Quantify/Jprof) of http://www.world-direct.com/mozilla/columniosity/inbrowser.html

Can anyone help regarding comment #16 ?

This is data for the URL in comment #16. Time wise pretty much what you would expect. The call count is interesting, 4 million calls to the nsCOMPtr destructor. These numbers were over a about a 30 second period

This is data for the URL in comment #16. Time wise pretty much what you would expect. The call count is interesting, 4 million calls to the nsCOMPtr destructor. These numbers were over a about a 30 second period

Is that a known issue - resp. being worked on?

This should reduce the call count of the nsCOMPtr dtor, FWIW

The right way to fix this kind of problem is to deCOMtaminate methods like GetDeviceContext() so it just returns the device context as a raw pointer directly, without adding a ref. Then you can write nsIDeviceContext* dc = aContext->GetDeviceContext(); if you don't want to hold a ref, or nsCOMPtr<nsIDeviceContext> dc = aContext->GetDeviceContext(); if you do want to hold a ref. Almost all the time, adding and releasing the ref is pointless because the object will be strongly referenced from somewhere else over the whole interval. This is what we're doing in layout.

roc and I are thinking along the same lines wrt the Right Way To Fix This. Attachment 127012 [details] [diff] is just for testing purposes to confirm that this is where the high call count for nsCOMPtr_base::~nsCOMPtr_base is coming from. In any case, I don't expect a huge impact on timing to come from this.

The patch doesn't seem to have any appreciable effect on the nsCOMPtr destructor call count. Here's what I see from Purify: Top five callers of ~nsCOMPtr: StyleSetImpl::AddImportantRules 142708 nsBindingManager::GetOutermostStyleScope 126908 nsBindingManager::WalkRules 125539 nsEventStateManager::GetContentState 110577 nsHTMLReflowState::InitConstraints 93404 Top five things released: PermanentAtomImpl::Release 540980 PresShell::Release 108841 nsXMLDocument::Release 87493 StyleSetImpl::Release 67715 FrameManager::Release 64426 StretchDIBits and StretchBlt are the major consumers of time. Each is calls a little over 850 times and are the most time consuming functions oustide of blocking functions. Both are called by nsImageWin::Draw New is called a fair bit and consumes a fair amount of time also. It was called over 90,000 times. It's top five callers are: nsSpaceManager::PushState 5686 NS_AllocateContiguousHandleWithData 3425 nsXULElement::Create 2921 nsXULPrototypeElement::Deserialize 2479 nsCSSSelectorList::AddSelector 1952 While these are the top 5 callers there were 16 functions that called new more than a 1,000 times. And many more that called it several hundred times. BitBlt is also consuming a lot of time, but isn't called a lot, 134 times. It's callers are: nsRenderingContextWin::CopyOffScreenBits 81 nsImageWin::BlitImage 51 nsWindow::DefaultWindowProc 2 Malloc is called 110,583 times, JS_malloc is the heaviest user with 30% of the calls. nsStrPrivate::Alloc is the next biggest user, and seems to stem from a lot of UTF16 to UTF8 conversion. With the NS_NewAtom being the biggest source of that. Memcpy is called a fair bit too. It's top callers are: UTF8InputStream::Read 39412 Called by nsPersistentProperties::Read nsBufferedInputStream::Read 18352 Called by nsFastLoadFileReader::Read PL_DHashMoveEntryStub 15005 Called mostly by RuleHash::EnumerateTagRules/EnumerateAllRules nsStrPrivate::Realloc 14776 UTF16->UTF8 conversion gfxImageFrame::SetImageData 10119 Hopefully some of this will shed some light on things.

Another observation, StyleSetImpl::AddImportantRules appears to be the source for a lot of calls to PR_Lock, through nsGetServiceByCID and nsCOMPtr_base::assign_from_helper

Hmm... It sounds like that purify data includes startup.... (the XBL and XUL fastload parts). > StyleSetImpl::AddImportantRules 142708 Could make GetImportantRule return a weak ptr for some win here.... > nsBindingManager::GetOutermostStyleScope 126908 This has a while loop with nsCOMPtr decls inside, hence the destructor count, I would assume. > nsEventStateManager::GetContentState 110577 Same. > PermanentAtomImpl::Release 540980 I wonder how much of this comes from the frame type atoms... > Another observation, StyleSetImpl::AddImportantRules appears to be the source > for a lot of calls to PR_Lock, through nsGetServiceByCID Um... that function does not get any services....

In theory there should be no startup data, as I ckeared data after the page was loaded. But I'm skeptical of what that actually does for Purify.

Caillon's patch in bug 83536 seems to help out here. nsScriptSecurityManager::LoopkupPolicy is no longer at the top caller for PL_DHashTableOperate and moves the hashing functions way down on the list of time spent.

I've attached a patch in bug 213813 that might help with some of these DHTML issues. I don't expect tremendous gains, but it might be a small step in improving performance. I'm going to try and get some numbers, but I wanted to get this out to others that might have more time than I have current. The patch is at http://bugzilla.mozilla.org/attachment.cgi?id=128862&action=edit

I'm not sure if this bug is really a huge problem anymore. I just ran the testcase in the URL and it's showing ~40% CPU utilization now. I'm guessing a fair number of DHTML performance improvements have gone in in the last two years. So, safe to mark WFM?

Running http://wd-testnet.world-direct.at/mozilla/columniosity/inbrowser.html with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060411 Firefox/3.0a1 I still get 99% cpu usage. Probably bug 326273 might bring here some improvement as well.

CPU usage isn't a very good indicator. 40% may be indicating that your CPU is twice as fast as the people reporting issues, you're encountering page faults, your video drivers are better, or your video card has better hardware accelleration. The only way to know if this bug has gotten better is to try it on a 1.1ghz 512meg ram system. You'll still have the video aspect as a variable as well as various XP patches since 2002.

The tested system has 1.8 ghz, 1GB RAM and a 128 RAM Nvidia video card.

with http://wd-testnet.world-direct.at/mozilla/columniosity/inbrowser.html i also can still confirm high CPU usage on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070417 Minefield/3.0a2pre ID:2007041704 [cairo]

Moved testcase to http://www.brandflow.at with two versions: http://www.brandflow.at/mozilla/columniosity/inbrowser.htm http://www.brandflow.at/mozilla/columniosity/index_fullscreen.htm

Please attach testcases directly to the bug so they won't get lost.

In all tested browsers: Fx3beta5pre, IE7, Op9.5beta, WebKit nightly the testcase took whole CPU, but it was quite smooth. It took less than 50% only in Fx2 (tested in Fx2, K-meleon and Flock all based on Gecko 1.8). Looks like a regression to me, but not sure how to identify it more precisely.

Profiling would help, but I suspect that it's just that doing the render takes 15ms, and we're being told to run the timer every 14ms. Is Fx2 as smooth? Above about 30fps (~33ms timeout activation) you might not notice a difference, but if we're firing the timers more frequently now, then you'd see increased CPU usage because we'd be doing more. "Using 100% CPU" isn't inherently a bug -- a CPU that's otherwise idle is wasted, all else being equal -- but if you think that we should be rendering that scene faster, such that there's idle time between timeouts, then you should probably file a specific bug about that, with profiling information and a rationale for investing in whichever parts you think need to be improved. I think this bug borders on INVALID, as summarized, but I'm not going to get all aggro about it just yet. :)

Having finally finished bug 266236 I thought I'd re-evaluate the test case here, but I can't find it anymore! None of the sites mentioned as troublesome still exist. I think it's best to close out this bug now and file a new one if there's still a problem.

(In reply to comment #39) > None of the sites mentioned as troublesome > still exist. FWIW, you can still get to the one mentioned in comment 11: http://replay.waybackmachine.org/20020722121714/http://dhtmlcentral.com/ This does spike my CPU on latest Firefox 4, but also on Chrome and MSIE 8. I suspect it's just the code or something, so I think you're totally right. Sorry if this is considered bugspam. -[Unknown]

I don't think saying "the testcase is here" can ever be considered bugspam.