- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 27 Feb 2006 01:51:14 -0800
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: "Web APIs WG (public)" <public-webapi@w3.org>
On Feb 27, 2006, at 1:15 AM, L. David Baron wrote: > On Sunday 2006-02-26 15:07 -0800, Maciej Stachowiak wrote: >> These don't necessarily have to be the tightest possible bounds. For >> example, requiring Node.nextSibling to be O(1) might limit >> implementations too much and an upper bound of O(log N) might be >> sufficient. Sometimes there are also information-theoretic limits to > > Mozilla's implementation of Node.nextSibling is O(N) in the number of > (prior) siblings of the element. Are you sure? I tried this test, with varying numbers of spans in the div. With an O(N) implementation of nextSibling, it should be taking O (N^2) time in the number of spans, but the scaling seems to be linear in Firefox 1.5 as expected. With ~2000 spans I get a time of 134, which is about 2x the 68 I get with ~1000. So that's evidence that it is at least amortized constant time. <div id="foo"> <span></span> </div> <script> window.onload = function() { var foo = document.getElementById("foo"); var n = foo.firstChild; var startTime = new Date(); while (n) { n = n.nextSibling; } var endTime = new Date(); alert(endTime - startTime); } </script> Similarly with this test I could not find any change in the timings regardless of number of spans before the "nextToLast" span, even when I added tens of thousands, which seems like evidence that it is in fact constant time: <div> <span></span> <span id="nextToLast"></span> <span></span> </div> <script> window.onload = function() { var n = document.getElementById("nextToLast") var startTime = new Date(); n = n.nextSibling; var endTime = new Date(); alert(endTime - startTime); } </script> Regards, Maciej
Received on Monday, 27 February 2006 09:51:29 UTC