Closed Bug 229391 Opened 21 years ago Closed 2 years ago

Slower than ideal (3D) DHTML performance

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: simon, Unassigned)

References

(
URL
)

Details

(Keywords: perf, testcase)

Attachments

(2 files, 2 obsolete files)

testcase as separate htm file
12.46 KB, text/html
Details
Updated zipped-up HTML of profile
233.05 KB, application/zip
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 This 3D example of a rotating cube, that runs much slower in Mozilla1.6b than in IE6 on my AMD 800Mhz / win2000 with 99% cpu consumption compared to 75-80% with ie. Reproducible: Always Steps to Reproduce: 1. open the url 2. just click on start/stop Actual Results: slow performance, high memory usage Expected Results: smother rendering of cube
Wow, yeah, we're really slow on this. Would be nice to get a profile. And a more accurate testcase to measure it. This test seems to involve a lot of adding and removing elements and positioning them, so it might even be quite a realistic test.
Keywords: perf
(o133885)
Profile is at bug 195408 comment 17.
Simon: If you want to make a testcase out of this, see http://www.hixie.ch/tests/adhoc/perf/dom/artificial/000.html ...for a template of sorts. You can look at other tests in that directory to see what some other performance tests look like. That would help us get actual numbers here, which make testing this a lot easier and accurate. Note that when comparing browsers, it is critical to: 1. Not have the mouse cursor in the window 2. Have windows the same size The following page can help with the second of those: http://www.hixie.ch/tests/adhoc/perf/prepare.html
The top item in the profile is this AlreadyInQueue thing... That could be made better by having the queue not be an array (since then building up the queue would not be O(N^2) in the length of the queue). That makes it somewhat difficult to guarantee in-order processing of the queue, however... Perhaps one could use a hashtable to guarantee uniqueness and an array for the ordering and add to both? As for the rest of the profile, it looks like standard stuff -- style reresolution, mostly. I assume the testcase sets a bunch of style properties one right after another all off a single timeout?
Blocks: 21762
Summary: Slow (3D) dhtml performance compared to ie → Slow (3D) DHTML performance compared to ie
Ian, I would like to create a testcase, but give me some time, I will be gone snowboarding the next days. I tried to reduce the creation/destroying of elements and the setting of style properties to a minimum. I basically create 368 div elements at the beginning (pixels) and then start the timeout, which only moves the elements around (set top/left properties).
See also the post I just made to n.p.m.style with a proposal that may end up helping out a good bit here.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
Hi everyone I created a testcase. Go to the url above and click the link to the mozilla testcase. Here are my measurements on an AMD 900Mhz, Windows 2000: *** Moz1.6b *** small cube: Elapsed time: 12'447 ms Average per loop: 248.94 ms Fastest loop: 210 ms Slowest loop: 290 ms big cube: Elapsed time: 30'916 ms Average per loop: 618.32 ms Fastest loop: 421 ms Slowest loop: 761 ms *** IE6 *** small cube: Elapsed time: 3'475 ms Average per loop: 69.50 ms Fastest loop: 60 ms big cube: Elapsed time: 7'009 ms Average per loop: 140.18 ms Fastest loop: 120 ms Slowest loop: 161 ms Slowest loop: 91 ms
On the testcase in comment 9, of the total 3216 jprof hits, we have: 244 under PresShell::ProcessReflowCommands 143 under nsArraySH::GetProperty (mostly GetItemAt and classinfo's WrapNative) 719 under CSS2PropertiesTearoff::SetTop 670 under CSS2PropertiesTearoff::SetLeft 164 under CSS2PropertiesTearoff::SetVisibility 281 under nsScriptSecurityManager::CanAccess (see bug 213946 for where most of that time is) The rest is in minor other stuff, JS engine itself, etc. Under SetTop and company, the breakdown is: 1552 total under nsDOMCSSDeclaration::SetProperty 323 of that under CSSParserImpl::ParseProperty 513 of that under FrameManager::ComputeStyleChangeFor 303 of that under ApplyRenderingChangeToTree 161 of that under PresShell::AppendReflowCommand that last one, 2/3 is the AlreadyInQueue check mentioned in comment 5 and 1/3 PostReflowEvent (event queue getting, monitors, etc, etc). So the testcase is showing mostly the things we already knew: 1) Security manager could be improved a bit 2) Batching style reresolves would help a _lot_ in cases when multiple style props are all set in a row 3) AlreadyInQueue() can make posting of reflow commands O(N^2) in the number of commands
I filed bug 230170 on the style reresolution stuff that's been talked about recently.
Blocks: 213946, 230170
AlreadyInQueue sure could use a hash queue. One implementation idea: drop the nsVoidArray, create a PLHashTable whose entry struct derives from PLHashEntry but mixes in PRCList, so live entries can be kept in a doubly-linked list; both unlink and search are thus O(1). /be
No longer blocks: 213946, 230170
Depends on: 213946, 230170
Depends on: 240934
I checked with the new Mozilla 1.8a4, Mozilla is still behind IE6, see test results on same machine as #8. Remark: Overall speed is way better an closer to IE now, but rendering seems to happen in bursts. *** Moz 1.8.a *** small cube (369 div): Elapsed time: 4'919 ms Average per loop: 98.38 ms Fastest loop: 80 ms Slowest loop: 120 ms big cube (729 div): Elapsed time: 10'033 ms Average per loop: 200.66 ms Fastest loop: 150 ms Slowest loop: 290 ms *** IE 6 *** small cube: Elapsed time: 3'334 ms Average per loop: 66.68 ms Fastest loop: 50 ms big cube: Elapsed time: 6'751 ms Average per loop: 135.02 ms Fastest loop: 110 ms Slowest loop: 160 ms Slowest loop: 90 ms
OK, I just did a profile of the large cube in a current (last night's, so it should include the view update batching changes) build. Ccing roc, since some of the view stuff comes up.... The basic info: Total hits: 242221. Of these: 21395 under PresShell::ProcessReflowCommands. Of these 12648 are under nsViewManager::MoveViewTo, mostly calling into nsRegionGTK::Union. Bug 243726 covers this last part, mostly. 16678 under nsCSSFrameConstructor::ProcessPendingRestyles. 18316 under nsScriptSecurityManager::CanAccess (covered by bug 213946 already) 70760 under nsDOMCSSDeclaration::SetPropertyValue The rest.... Of the total 180927 hits under js_Execute, only 89000 are accounted for above. The rest are in JS, XPConnect, classinfo. Of particular note are: 14741 under js_NumberToString 11468 under nsXPConnect::WrapNative 13834 under js_LookupPropertyWithFlags I'll attach the profile to this bug for people's perusal. I looked a bit further into nsDOMCSSDeclaration::SetPropertyValue. The breakdown under that is: 35089 under CSSParserImpl::ParseProperty 27745 under nsDOMCSSAttributeDeclaration::DeclarationChanged which fritters along minor things, then calls AttributeChanged (15000 hits under that). Of particular interest under this last part is 6294 under nsEventQueueServiceImpl::GetSpecialEventQueue (bug 240874) The property parsing is about a third under nsCSSScanner::ParseNumber and another third initing/releasing scanners and decompressing/recompressing/transferring the style data. The rest is scattered here and there.
Depends on: 240874, 243726
Attached file Zipped-up HTML of profile (obsolete) —
Depends on: 263959
Depends on: 263973
It seems to me that making "foo.style = ..." go through parsing and the full style reresolution mechanism is rather a waste. Can't we detect when the inline style is the most specific, and then treat such assignments as directly setting the style data?
Even directly setting the style data involves parsing, though... Furthermore, depending on which properties are being set, other properties' values will need to change (eg float affects display, position affects float, font-size affects the meaning of em units for everything in sight, etc). Add to this the fact that we have to clear out cached style data, possibly, and that changing .style.foo on a node can affect its kids. Once all that's taken into account, what we end up with may not be much faster than just reresolving... :( On an unrelated note, I just realized that I never said how much time painting took on that testcase. There were about 3500 hits under UpdateIdle().
Depends on: 267179
This bug seems to be a dupe of bug 195408. But I won't touch it. Also the testcase is 404.
#18 Testcase should work again. Website was down temporarily (provider migrated website...)
Simon, the testcases seems to be gone again (I just get a blank blue page, more or less)....
Depends on: 288369
Boris, Testcase should be up and running again. Sorry for the inconvenience. Simon
Attached file testcase as separate htm files (obsolete) —
Attachment #179157 - Attachment is obsolete: true
The patch I checked in today for bug 288369 should help with the jerkiness pointed out in comment 13...
Depends on: 288574
I downloaded the latest build today [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050521]. Here my results for the big cube (unfortunately on a new machine): --- Moz 1.8b2 --- Elapsed time: 3'362 ms Average per loop: 67.24 ms Fastest loop: 47 ms Slowest loop: 109 ms -- Ie 6.0 --- Elapsed time: 2'527 ms Average per loop: 50.54 ms Fastest loop: 31 ms Slowest loop: 63 ms --- Fox 1.0.4 --- Elapsed time: 10'514 ms Average per loop: 210.28 ms Fastest loop: 140 ms Slowest loop: 250 ms Yes, getting faster and faster.
Depends on: 289655
Depends on: 314920
Depends on: 311566
Simon, I'd be curious in seeing what tomorrow's trunk nightlies look like on your machine... Also, I recommend comparing to Opera, not just IE -- in my experience Opera is a _lot_ faster than we are... :(
--- Opera 8.5 --- Elapsed time: 2'107 ms Average per loop: 42.14 ms Fastest loop: 31 ms Slowest loop: 47 ms --- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051116 Firefox/1.6a1 --- Elapsed time: 3'032 ms Average per loop: 60.64 ms Fastest loop: 46 ms Slowest loop: 94 ms --- IE 6 --- Elapsed time: 2'639 ms Average per loop: 52.78 ms Fastest loop: 46 ms Slowest loop: 63 ms Boris, as you guessed. Opera beats IE. Hope I downloaded the right nightly.
Yeah, that looks like the right nightly. OK. So we're doing OK, not great. Thank you!
Out of curiousity, what effect, if any, did the fix for bug 317375 have on this? That is, how does a trunk build from 2006-01-24 or earlier compare to a current trunk build?
Hi Boris I'm not sure if I understand the terminology right (trunk build?). So if I download a nightly build from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2006-01-23-11-trunk/ run the test and then download a build from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2006-02-01-11-trunk/ and run the test again that would help you ?
Simon, that's exactly right. Thanks!
Here are the numbers. I repeated it 3 times. There seems to be no difference between the builds... Gecko/20060123 Gecko/20060201 Opera 8.51/7712 3'359 ms 3'471 ms 2'312 ms 67.18 ms 69.42 ms 46.24 ms 46 ms 47 ms 31 ms 94 ms 94 ms 78 ms 3'563 ms 3'515 ms 2'094 ms 71.26 ms 70.30 ms 41.88 ms 46 ms 46 ms 31 ms 110 ms 140 ms 47 ms 3'250 ms 3'454 ms 2'375 ms 65.00 ms 69.08 ms 47.50 ms 46 ms 46 ms 31 ms 125 ms 109 ms 78 ms
OK, great. That patch wasn't expected to make things immediately faster or anything; just making sure it didn't get slower. ;)
I'd be interested in how today's builds (which have bug 326273 fixed) do.
Unfortunately, I never tested this bug in a build prior to today, but here are my results for the big cube. Current 5-11-2006 Trunk: Elapsed time: 1'905 ms Average per loop: 38.10 ms Fastest loop: 31 ms Slowest loop: 62 ms IE6: Elapsed time: 1'405 ms Average per loop: 28.10 ms Fastest loop: 15 ms Slowest loop: 32 ms
Interesting. Either we got a lot slower, or the hardware matters; see comment 27.... fwiw, you can get builds from day before yesterday off FTP easily enough.
Never mind comment 36; I misread comment 27.
Aren't these post-cairo-turnon numbers?
More data for you: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060507 Minefield/3.0a1 Elapsed time: 2'500 ms Average per loop: 50.00 ms Fastest loop: 40 ms Slowest loop: 80 ms Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060511 Minefield/3.0a1 Elapsed time: 2'153 ms Average per loop: 43.06 ms Fastest loop: 30 ms Slowest loop: 51 ms So yeah, a definite speed win.
Crap, forgot the IE numbers Elapsed time: 1'904 ms Average per loop: 38.08 ms Fastest loop: 30 ms Slowest loop: 61 ms Sorry for the spam.
So I did a profile of this with a current build on Linux (with threadmanager changes and all). Rough breakdown of where time is spent: 15% recomputing style data 14.5% parsing CSS 10.6% changing the inline style rule. About 1/3 of this is in nsCSSFrameConstructor::AttributeChanged; the rest is Begin/EndUpdate, copying observer lists, setting the nsAttrValue, etc. 7% converting numbers to strings in JS 6.7% under js_LookupProperty; a bit more than half of this is in XPConnect 6.6% layout 6.1% getting properties from a nodelist (presumably getting at divs?). About 2/3 of this is spent creating XPConnect wrappers for the native objects. 5.3% security checks 4.6% painting 1.7% JS GC Of the remaining 20% or so, at least 3/4 is mostly scattered in JS and XPConnect as far as I can tell...
Attachment #161608 - Attachment is obsolete: true
The animated 3d box at provided URL also shows the same, exact painting symptoms as described in a similar bugfile (bug 30782: Animation with some text have some problem drawing pixels). At both URLs of these bugs and at http://www.taboca.com/worlds/gek/webfilmed/intro2/3dcircle3.html we can see small streak of pixels not being repainted, small lines of residual pixels.
> also shows the same, exact painting symptoms This bug's testcase shows those symptoms in all browsers (or at least Konqueror, Opera, IE/Windows, and Gecko), leading me to think that the page is just coded to have that effect. > http://www.taboca.com/worlds/gek/webfilmed/intro2/3dcircle3.html I don't see the problem there on Linux, for what it's worth. It probably depends on the invalidation differences between the platforms...
To #42/43: I never checked if the streaks of pixels not beeing repainted is a bug or lies in my coding (I think it's the latter, but I havn't had the time to check...). But it was certainly not the reason to post this bug, which is about speed.
I made a comparison with the current browsers and the latest seamonkey build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061124 SeaMonkey/1.5a. Still same machine as #25 but on Windows XP not Win2000. OP 9.02 Elapsed time: 1'968 ms Average per loop: 39.36 ms Fastest loop: 31 ms Slowest loop: 62 ms IE 7.0 Elapsed time: 2'595 ms Average per loop: 51.90 ms Fastest loop: 31 ms Slowest loop: 63 ms FF 2.0 Elapsed time: 3'638 ms Average per loop: 72.76 ms Fastest loop: 47 ms Slowest loop: 109 ms SM 1.5a Elapsed time: 3'643 ms Average per loop: 72.86 ms Fastest loop: 47 ms Slowest loop: 94 ms To #42-44: Residual pixels are not a bug. For speed reasons 729 pixels (divs) are created at once at the beginning and then just moved around. No DOM node manipulation (appendChild, removeChild). So depending on the position of the cube more or less pixels out of the initially created ones are reused. BTW: Inline spell check is great, especially for nonnative speakers, I mean writers...
Can someone do a new profile on this one?
For what it's worth, there's no point to running this test or profiling it at least until the reflow branch has landed. Possibly also not until the textframe rewrite has landed, though this test may not be too sensitive to that. Until that happens, this is pretty much guaranteed to be like it was on the 1.8 branch (as the test in comment 45 shows).
I hope I got it right, that the current GrandParadiso 3.0a3 [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3) Gecko/20070322 GranParadiso/3.0a3] contains the reflow branch [see #47], otherwise sorry for bothering everyone. Its a bit slower, but whats worse is, that now many frames are just dropped. Sometimes only about 15 out of 50 frames are displayed, all the others are skipped (especially if I have another program open). The numbers: Elapsed time: 3'905 ms Average per loop: 78.10 ms Fastest loop: 62 ms Slowest loop: 94 ms
1.9a3 does contain reflow branch. That said, I spent some time testing this testcase with reflow branch builds, and never saw frame dropping (on a P3-733, at that). I still don't see it on trunk (on Linux)... If you _do_ see it on Windows, please file a regression bug? And maybe see whether you can narrow down the first nightly when it started?
Boris, I did see the skipping on Windows with the same machine as #45. But I realized, that I had some extensions installed... ... I removed all my extensions (Firebug, Html Validator, Adblock) and then the frame dropping was gone. But interestingly, as soon as I had a few extensions installed (although they were automatically disabled by GranParadiso), the frame dropping occurred again. The dropping didn't seem to cone from a specific extension, but I couldn't find out exactly on what it depended.
Interesting! Can you file a bug on that? And maybe hunt down a regression range? Frame dropping is a serious issue that should be blocking 1.9, imo.
JavaScript performance in general seems to have taken a hit (bug 375225, bug 375227) since bug 333078 was checked in.
Yes, but the frame dropping is not necessarily a performance issue. For what it's worth, I'm working on getting those bugs profiled...
#51: Can someone give me a hint where/how I would get the necessary files (file naming)? First in the range - last in range ? Ok, I'll file a bug in the next few days.
Simon, ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly has dated directories... If you need older builds, http://archive.mozilla.org
I filed new bug 377380.
Boris, I did some testing to hunt down a regression range. I published the results in bug 377380.
Depends on: 402491
it's WFM on Windows XP with latest nightly vs. IE7. Fx3beta4pre Elapsed time: 1'366 ms Average per loop: 27.32 ms Fastest loop: 23 ms Slowest loop: 29 ms IE7 Elapsed time: 1'611 ms Average per loop: 32.22 ms Fastest loop: 16 ms Slowest loop: 47 ms reopen if needed
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Comparing performance to IE7 is not that useful nowadays. How do Opera and Safari do?
new machine (not same as in #45) Opera 9.26 Elapsed time: 1'016 ms Average per loop: 20.32 ms Fastest loop: 15 ms Slowest loop: 32 ms IE7 Elapsed time: 1'126 ms Average per loop: 22.52 ms Fastest loop: 15 ms Slowest loop: 32 ms FF 3.0b5pre Elapsed time: 1'148 ms Average per loop: 22.96 ms Fastest loop: 19 ms Slowest loop: 25 ms
Oh well, I'm sorry, but I found out, that I didn't measure the overall time correctly. What I measured was the overall time spent in the Loop() function, but this did not include the time spent between the setTimeout() calls (even though the timeout was set to zero. But, only in an ideal world setTimeout("Loop()", 0); would actually take no time to call the Loop function again...). As a consequence I added a new test parameter, the new 'Time in Loop' is the former 'Elapsed time' and 'Elapsed time' is now the overall time spent for the whole animation. 'Average per loop', 'Fastest loop' and 'Slowest Loop' are the same as before. So here are the new numbers : Minefield/3.0b5pr Gecko/2008030607 Elapsed time: 1'816 ms Time in Loop: 1'173 ms Average per loop: 23.46 ms Fastest loop: 19 ms Slowest loop: 25 ms Opera 9.26 Elapsed time: 2'469 ms Time in Loop: 942 ms Average per loop: 18.84 ms Fastest loop: 15 ms Slowest loop: 32 ms Safari 3.04 Win Beta Elapsed time: 2'484 ms Time in Loop: 686 ms Average per loop: 13.72 ms Fastest loop: 0 ms Slowest loop: 16 ms FF 2.0.0.12 Elapsed time: 2'875 ms Time in Loop: 1'812 ms Average per loop: 36.24 ms Fastest loop: 31 ms Slowest loop: 47 ms BTW: This script is also used in the webkit's Sunspider 0.9 benchmark.
Yeah, and we do just fine on that script in the SunSpider context; profiling is going to be needed to drive actual improvements here (as it was in the pure-script case, quite successfully).
Oh, so the original testcase was excluding the actual time needed to recompute the layout (since UAs do that async), right? I was profiling the full animation, so I think my profiles were picking up your new "Elapsed time" metric. As for profiling, last profile I did here indicated that the main costs were the expensive double-to-string and string-to-double conversions when setting top/left, XPConnect overhead, CSS parsing in general. I'll do another profile sometime in June, probably. I do think we should reopen this bug. Resummarizing while I'm at it.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Summary: Slow (3D) DHTML performance compared to ie → Slower than ideal (3D) DHTML performance
Boris, I do not understand enough of the subject to really confirm what you are saying, but I think you are right. The whole animation is done by calling the setTimeout('Loop()', 0) function from inside the Loop() function with a delay of 0 miliseconds. All the calculations of the pixel's coordinates and the setting of their positions (e.g. div.style.top/left) are also done from within the Loop() function by calling other functions such as Rotate(), Translate(), DrawCube(), etc. 'Time in Loop' (= 'Elapsed time' in original testcase) is measured by calling new Date() inside the Loop() function at the beginning and again at the ending, and then adding the difference up everytime Loop() is called. pseudocode: Loop() { Start measure time; // for 'time in Loop' Calculate cube's position; Draw cube; Stop measure time and add it to previously measured time; setTimeout('Loop()', 0); ; So, do I get it right by saying: *If* the layout was computed in sync, then 'Time in Loop' would become the same as 'Elapsed time', because nothing outside of the setTimeout would happen (e.g. finish recomputing layout) ?
If layout (and painting, etc) were sync, then elapsed time would be time in loop plus (10ms * (number of loops)), since setTimeouts for times smaller than 10ms are set for 10ms from now. Sounds like we're on the same page. I'm actually pretty impressed that we're managing to beat Opera for total time, even with the handicap from the time in loop! Once we fix some of the issues impacting that, life will be pretty sweet. ;)
I've been working with the sunspider tests recently and while working with 3d-cube i came across this bug. And since the last numbers posted are pre Chrome, IE 8 and many other browsers. I went through and ran the numbers. http://cznp.com/3d-cube-04.06.2009.txt Hope it helps some. Thanks.
Depends on: 498559
Depends on: 498562
Depends on: 498565
Assignee: layout → nobody
QA Contact: ian → layout
just some new numbers with FF 3.6b3: FF 3.5.5 FF 3.6b3 Opera 10 Safari 4 Chrome 3 Elapsed time 1702 1288 672 981 822 Time in loop 1003 580 343 425 504 Average per loop 20.26 11.6 6.86 8.5 10.08 Fastest loop 17 9 0 7 8 Slowes loop 23 13 16 10 24
Testing the big cube from the new link: Nightly 27 Elapsed time: 3'798 ms Time in Loop: 1'515 ms Average per loop: 30.30 ms Fastest loop: 24 ms Slowest loop: 49 ms Chrome 29 Elapsed time: 1'397 ms Time in Loop: 199 ms Average per loop: 3.98 ms Fastest loop: 3 ms Slowest loop: 11 ms IE 10 Elapsed time: 2'536 ms Time in Loop: 1'580 ms Average per loop: 31.60 ms Fastest loop: 26 ms Slowest loop: 63 ms
Would be useful to have a testcase here that runs for a controllable period of time, to aid profiling....
Keywords: qawanted
@Boris: Can you explain what you mean/need for the test case. I have vacation starting this weekend and will take time to update the test case. Btw: Nice to see that this test case is still useful after 10 year!
Simon, what I'd like to be able to do is have the cube keep rotating for 30 seconds or so, so that I can profile it. Also useful would be a cube that keeps rotating for 30 seconds or so but doesn't do it off setTimeout: so basically a while loop that keeps updating the positions but not yielding to paint. That would allow isolating the update times and paint times from each other.
I guess it defeats the purpose of this testcase, if I replace the setting of the style properties with just setting a class, e.g. // replace el.style.top = Y + 'px'; el.style.left = X + 'px'; el.style.visibility = 'visible'; el.style.height = '1px'; el.style.width = '1px'; el.style.margin = '0px'; el.style.padding = '0px'; el.style.position = 'absolute'; el.style.border = '0px'; el.style.backgroundColor = '#000000'; // with el.style.top = Y + 'px'; el.style.left = X + 'px'; el.className = 'point'; // where point is all of the above
Yes, that would significantly change the behavior.
I created a revised testcase, which lets you set the time or the number of iterations as well as if setTimeout() should be called or not. Here are some numbers of FF 24 vs Chrome 30: // Firefox 24 test method:time, using timeout of 0 cube size:medium (729 divs) elapsed time:10025 ms time in Loop:5092 ms average per loop:20 ms fastest loop:16 ms slowest loop:31 ms # of loops:261 test method:time cube size:medium (729 divs) elapsed time:10018 ms time in Loop:10016 ms average per loop:19 ms fastest loop:15 ms slowest loop:23 ms # of loops:524 // Google Chrome test method:time, using timeout of 0 cube size:medium (729 divs) elapsed time:10016 ms time in Loop:1152 ms average per loop:2 ms fastest loop:1 ms slowest loop:4 ms # of loops:600 test method:time cube size:medium (729 divs) elapsed time:10001 ms time in Loop:9992 ms average per loop:1 ms fastest loop:1 ms slowest loop:7 ms # of loops:7032
Dropping qawanted based on comment 74.
Keywords: qawanted
Severity: normal → S3

Seems very fast now.

Status: REOPENED → RESOLVED
Closed: 17 years ago → 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: