On Thu, 18 Mar 2010 01:29:14 +0100, Maciej Stachowiak m...@apple.com
wrote:
We're probably going to make a change to do caching in WebKit, and we
would still like to see appropriate errata to DOM Level 3 Core. Do we
have anyone who is officially empowered to edit the errata? I can
suggest
On Sat, 13 Feb 2010, Boris Zbarsky wrote:
On 2/13/10 6:18 AM, Ian Hickson wrote:
I'm concerned about the GC-sensitivity of such behaviour (we might end
up snookering ourselves in a situation where specific GC behaviour
actually matters for compatibility).
We haven't gotten there yet,
On Mar 17, 2010, at 4:22 PM, Ian Hickson wrote:
On Sat, 13 Feb 2010, Anton Muhin wrote:
For me performance-wise both approaches seem fine, but to get
numbers I
need to run an experiment.
My main concern would be that rules are overcomplicated imho. And I
won't be surprised if IE and FF
On Fri, Jan 22, 2010 at 5:11 AM, Anton Muhin ant...@chromium.org wrote:
Good day.
Currently DOM core 3 spec is somewhat inconsistent regarding if
invocations of getElementsByTagName and alike must return a new
NodeList or could cache this list. For Document it's mandated for
both
For me performance-wise both approaches seem fine, but to get numbers I need
to run an experiment.
My main concern would be that rules are overcomplicated imho. And I won't
be surprised if IE and FF would just ignore them. But you understand all
those matters better than I do.
BTW, as the
On 2/13/10 6:18 AM, Ian Hickson wrote:
I'm concerned about the GC-sensitivity of such behaviour (we might end
up snookering ourselves in a situation where specific GC behaviour
actually matters for compatibility).
We haven't gotten there yet, in 8 years of two different implementations
having
On Feb 13, 2010, at 3:18 AM, Ian Hickson wrote:
On Fri, Jan 22, 2010 at 5:11 AM, Anton Muhin ant...@chromium.org
wrote:
Good day.
Currently DOM core 3 spec is somewhat inconsistent regarding if
invocations of getElementsByTagName and alike must return a new
NodeList or could cache this
On Fri, Feb 12, 2010 at 2:19 PM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 22 Jan 2010 14:11:40 +0100, Anton Muhin ant...@chromium.org wrote:
Is it possible to allow caching for those cases? Firefox caches those
node lists for a long time (Maciej found the related bug
On Feb 12, 2010, at 3:19 AM, Anne van Kesteren wrote:
On Fri, 22 Jan 2010 14:11:40 +0100, Anton Muhin
ant...@chromium.org wrote:
Is it possible to allow caching for those cases? Firefox caches
those
node lists for a long time (Maciej found the related bug
On Feb 12, 2010, at 3:47 AM, Maciej Stachowiak wrote:
On Feb 12, 2010, at 3:19 AM, Anne van Kesteren wrote:
On Fri, 22 Jan 2010 14:11:40 +0100, Anton Muhin
ant...@chromium.org wrote:
Is it possible to allow caching for those cases? Firefox caches
those
node lists for a long time
On Fri, 22 Jan 2010 14:11:40 +0100, Anton Muhin ant...@chromium.org
wrote:
Is it possible to allow caching for those cases? Firefox caches those
node lists for a long time (Maciej found the related bug
https://bugzilla.mozilla.org/show_bug.cgi?id=140758). IE8 caches as
well. Opera, Safari
On Fri, 12 Feb 2010 12:51:03 +0100, Maciej Stachowiak m...@apple.com
wrote:
On Feb 12, 2010, at 3:47 AM, Maciej Stachowiak wrote:
On Feb 12, 2010, at 3:19 AM, Anne van Kesteren wrote:
On Fri, 22 Jan 2010 14:11:40 +0100, Anton Muhin ant...@chromium.org
wrote:
Is it possible to allow caching
On Feb 12, 2010, at 5:05 AM, Anne van Kesteren wrote:
On Fri, 12 Feb 2010 12:51:03 +0100, Maciej Stachowiak
m...@apple.com wrote:
On Feb 12, 2010, at 3:47 AM, Maciej Stachowiak wrote:
On Feb 12, 2010, at 3:19 AM, Anne van Kesteren wrote:
On Fri, 22 Jan 2010 14:11:40 +0100, Anton Muhin
On Fri, 12 Feb 2010 14:13:57 +0100, Maciej Stachowiak m...@apple.com
wrote:
On Feb 12, 2010, at 5:05 AM, Anne van Kesteren wrote:
Is it really a lot of performance? Our developers are not that
convinced.
A patch that made the change in WebKit was measured as a 20% speedup on
the Dromaeo
On Feb 12, 2010, at 7:09 AM, Anne van Kesteren wrote:
On Fri, 12 Feb 2010 14:13:57 +0100, Maciej Stachowiak
m...@apple.com wrote:
On Feb 12, 2010, at 5:05 AM, Anne van Kesteren wrote:
Is it really a lot of performance? Our developers are not that
convinced.
A patch that made the change
On Feb 12, 2010, at 7:53 AM, Maciej Stachowiak wrote:
Also, what happens with garbage collection? Say some isolated piece
of code does:
x = document.getElementsByTagName(x)
x.p = 2
... and then later on some other piece of code does:
y = document.getElementsByTagName(x)
w(p in y)
On 2/12/10 8:05 AM, Anne van Kesteren wrote:
Is it really a lot of performance? Our developers are not that convinced.
It depends on your use case.
If you're actually using getElementsByTagName on a largish DOM, then the
performance effect of not having to walk that DOM multiple times is in
On 2/12/10 10:09 AM, Anne van Kesteren wrote:
It would be interesting to know what exactly that test is. Optimizing
for benchmarks is not always useful :-)
Point 1: Optimizing for benchmarks is sadly all that people report on.
They don't even bother making up new benchmarks, so you can
On Feb 12, 2010, at 8:29 AM, Boris Zbarsky wrote:
Test 1: ~4350ms
Test 2: ~2100ms
Test 3: ~80ms
Test 4: ~10ms
and in Opera 10.5 pre alpha:
Test 1: ~520ms
Test 2: ~3809ms
Test 3: ~541ms
Test 4: ~3828ms
and in Safari 4:
Test 1: ~260ms
Test 2: ~1309ms
Test 3: ~131ms (?)
Test 4: ~20ms
Given
Hey folks,
Any thoughts on this? I think it would be wise to issue an errata against DOM 3
Core to allow caching of NodeLists, and make sure to fix this in DOM4. IE and
Firefox seem to do it, and it can be a big performance benefit, so I think the
DOM spec should allow it.
The three errata
I definitely am in favor of this, unsurprisingly given that we've
chosen to do this in Firefox.
/ Jonas
On Tue, Feb 2, 2010 at 5:02 PM, Maciej Stachowiak m...@apple.com wrote:
Hey folks,
Any thoughts on this? I think it would be wise to issue an errata against DOM
3 Core to allow caching of
21 matches
Mail list logo
