Re: [webkit-dev] Why are PassRefPtr<>s used as function parameters?

[Geoffrey Garen]

I don't see why the distinction between a callee simply using an  
object or adopting it for future use is terribly interesting to the  
caller.


Agreed. And let's avoid making it interesting!

The whole point of reference counting is to ensure that one object can  
reference a piece of data without knowing or caring whether another  
object references that data.


Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why are PassRefPtr<>s used as function parameters?

[Jeremy Orlow]

My thinking is that we should be consistent.  And given that passing a raw
pointer is equal to or faster than passing a PassRefPtr it seems to me that
we should just do that whenever ownership isn't being transfered.  Note that
this is what's done in the majority of cases I've seen and it's what the
RefPtr doc recommends, IIRC.

I don't see why the distinction between a callee simply using an object or
adopting it for future use is terribly interesting to the caller.

J

On Thu, Oct 29, 2009 at 3:55 PM, Drew Wilson  wrote:

> Aside from the ref-counter munging, it still seems like there's value in
> using PassRefPtr as a signifier that a given API takes ownership of a
> pointer.
>
> So I'm not certain (in the case of HTMLNameCollection) that it'd be a
> better solution to change it not to take an ordinary pointer - yes, it would
> eliminate some ref churn, but at the cost of losing that connotation.
>
> A better solution (since the constructor is private) would be to make the
> constructor explicitly take a CollectionCache* parameter, thereby allowing
> us to directly pass the document straight through to the base class.
>
> -atw
>
>
> On Thu, Oct 29, 2009 at 3:31 PM, Maciej Stachowiak  wrote:
>
>>
>> On Oct 29, 2009, at 12:56 PM, Darin Adler wrote:
>>
>>  On Oct 27, 2009, at 10:55 AM, Jens Alfke wrote:
>>>
>>>  Looking at how refcounting is implemented in WebCore, I was surprised to
 find that there are a lot of functions/methods that take PassRefPtr<>s as
 parameters instead of regular pointers to those objects. I can't see any
 benefit to this, and it adds the overhead of a ref() and deref() at every
 call-site.

>>>
>>> Have you read the RefPtr document? It is at <
>>> http://webkit.org/coding/RefPtr.html>.
>>>
>>> Only functions that take ownership of the passed-in objects should take
>>> PassRefPtr. This makes it so we can optimally handle the case where that
>>> object was just created and lets us hand off the reference instead of having
>>> to do a round of reference count thrash. If the function is going to be
>>> storing the value in a RefPtr, then the PassRefPtr does not introduce any
>>> reference count thrash even if the passed in object was not just created.
>>>
>>> It’s wrong for the HTMLNameCollection constructor to take a PassRefPtr
>>> for its document argument because it doesn’t take ownership of the document.
>>> So that one is definitely a mistake.
>>>
>>
>> However, its base class HTMLCollection can take ownership. The
>> HTMLNameCollection constructor misses out on the optimization though:
>>
>> HTMLNameCollection::HTMLNameCollection(PassRefPtr document,
>> CollectionType type, const String& name)
>>: HTMLCollection(document.get(), type,
>> document->nameCollectionInfo(type, name))
>>, m_name(name)
>> {
>> }
>>
>> Note that it passes document.get(), but also uses document after that so
>> it couldn't just pass document. Thus, it probably shouldn't take a
>> PassRefPtr (unless there is a clever way to fix it that I'm not seeing).
>>
>>  - Maciej
>>
>>
>>
>>
>>> It is true that PassRefPtr arguments can be tricky as you mentioned and
>>> the RefPtr document also mentions.
>>>
>>>   -- Darin
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why are PassRefPtr<>s used as function parameters?

[Drew Wilson]

Aside from the ref-counter munging, it still seems like there's value in
using PassRefPtr as a signifier that a given API takes ownership of a
pointer.

So I'm not certain (in the case of HTMLNameCollection) that it'd be a better
solution to change it not to take an ordinary pointer - yes, it would
eliminate some ref churn, but at the cost of losing that connotation.

A better solution (since the constructor is private) would be to make the
constructor explicitly take a CollectionCache* parameter, thereby allowing
us to directly pass the document straight through to the base class.

-atw

On Thu, Oct 29, 2009 at 3:31 PM, Maciej Stachowiak  wrote:

>
> On Oct 29, 2009, at 12:56 PM, Darin Adler wrote:
>
>  On Oct 27, 2009, at 10:55 AM, Jens Alfke wrote:
>>
>>  Looking at how refcounting is implemented in WebCore, I was surprised to
>>> find that there are a lot of functions/methods that take PassRefPtr<>s as
>>> parameters instead of regular pointers to those objects. I can't see any
>>> benefit to this, and it adds the overhead of a ref() and deref() at every
>>> call-site.
>>>
>>
>> Have you read the RefPtr document? It is at <
>> http://webkit.org/coding/RefPtr.html>.
>>
>> Only functions that take ownership of the passed-in objects should take
>> PassRefPtr. This makes it so we can optimally handle the case where that
>> object was just created and lets us hand off the reference instead of having
>> to do a round of reference count thrash. If the function is going to be
>> storing the value in a RefPtr, then the PassRefPtr does not introduce any
>> reference count thrash even if the passed in object was not just created.
>>
>> It’s wrong for the HTMLNameCollection constructor to take a PassRefPtr for
>> its document argument because it doesn’t take ownership of the document. So
>> that one is definitely a mistake.
>>
>
> However, its base class HTMLCollection can take ownership. The
> HTMLNameCollection constructor misses out on the optimization though:
>
> HTMLNameCollection::HTMLNameCollection(PassRefPtr document,
> CollectionType type, const String& name)
>: HTMLCollection(document.get(), type,
> document->nameCollectionInfo(type, name))
>, m_name(name)
> {
> }
>
> Note that it passes document.get(), but also uses document after that so it
> couldn't just pass document. Thus, it probably shouldn't take a PassRefPtr
> (unless there is a clever way to fix it that I'm not seeing).
>
>  - Maciej
>
>
>
>
>> It is true that PassRefPtr arguments can be tricky as you mentioned and
>> the RefPtr document also mentions.
>>
>>   -- Darin
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why are PassRefPtr<>s used as function parameters?

[Maciej Stachowiak]

On Oct 29, 2009, at 12:56 PM, Darin Adler wrote:


On Oct 27, 2009, at 10:55 AM, Jens Alfke wrote:

Looking at how refcounting is implemented in WebCore, I was  
surprised to find that there are a lot of functions/methods that  
take PassRefPtr<>s as parameters instead of regular pointers to  
those objects. I can't see any benefit to this, and it adds the  
overhead of a ref() and deref() at every call-site.


Have you read the RefPtr document? It is at .


Only functions that take ownership of the passed-in objects should  
take PassRefPtr. This makes it so we can optimally handle the case  
where that object was just created and lets us hand off the  
reference instead of having to do a round of reference count thrash.  
If the function is going to be storing the value in a RefPtr, then  
the PassRefPtr does not introduce any reference count thrash even if  
the passed in object was not just created.


It’s wrong for the HTMLNameCollection constructor to take a  
PassRefPtr for its document argument because it doesn’t take  
ownership of the document. So that one is definitely a mistake.


However, its base class HTMLCollection can take ownership. The  
HTMLNameCollection constructor misses out on the optimization though:


HTMLNameCollection::HTMLNameCollection(PassRefPtr document,  
CollectionType type, const String& name)
: HTMLCollection(document.get(), type, document- 
>nameCollectionInfo(type, name))

, m_name(name)
{
}

Note that it passes document.get(), but also uses document after that  
so it couldn't just pass document. Thus, it probably shouldn't take a  
PassRefPtr (unless there is a clever way to fix it that I'm not seeing).


 - Maciej




It is true that PassRefPtr arguments can be tricky as you mentioned  
and the RefPtr document also mentions.


   -- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ThreadIdentifier abstraction is inefficient

[Dmitry Titov]

On Thu, Oct 29, 2009 at 3:10 PM, Anton Muhin  wrote:

> ens,
>
> Somewhat aside from ThreadIdentifier.
>
> Actually, at least for now, there should be no invocations of
> WTF::currentThread() at least for the renderer---everything should run
> in the same thread.


That sounds right. Same for Chromium Worker processes. Some time ago we
tried to run workers in the same process as renderer, or several workers in
the Worker process using v8 locking. It didn't work well so we abandoned the
idea. Seems like some good cleanup could help, nothing is as fast as not
running the code! :-)

As for previous attempt to fix the issue, there were 2 main concerns (to
recap):

- pthread_t is reused by some OSes between threads so comparing thread ids
may give false matches in case we just use pthread_t as TheradIdentifier.

- Safari apparently uses WTF directly from JSC and changing binary interface
and especially subtle protocol details will likely break nightly builds.
Optimally, someone with visibility into both codebases could fix this with
more confidence. Alternatively, perhaps such services as threading could be
provided by the embedder via WebKit API rather then implemented in WTF -
since embedders need access to the same time/thread services as the rest of
WebKit.

Dmitry
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ThreadIdentifier abstraction is inefficient

[Jens Alfke]

On Oct 29, 2009, at 3:07 PM, Anton Muhin wrote:


May you tell me which test(s) you run?


I saw this in Dromaeo's "DOM Query" test (the first one under "DOM  
Core Tests".) I believe it would also show up some of the other DOM  
tests, like DOM Modification, which also create and GC lots of DOM  
nodes.



And, overall, some time ago I failed to build Chromium w/ symbols (to
use Shark), may you teach me how to do that?


In chrome.xcodeproj, unfold the Targets list and find the "chrome_dll"  
target; then unfold that and click the final build step, "Postbuild  
'Strip If Needed'".

Open the inspector (File > Show Inspector).
Either delete both the strip and exit commands, or put "#"s in front  
of them.

Touch any source file in WebCore, then build.

—Jens
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Performance of NamedAttrMap

[Maciej Stachowiak]

On Oct 29, 2009, at 3:03 PM, David Hyatt wrote:

The order of the properties in both style declarations and in  
attribute maps is relevant for serialization that conforms to the  
original declared source order.


I think this is a standards compliance issue for style declarations  
(besides serialization there is an API to traverse them in order) but  
for attributes I don't think it is a compatibility issue in practice  
to give the original declaration order. Could be wrong though. If that  
does turn out to be necessary then a data structure like ListHashMap  
could provide fast associative access but also preserve order. That's  
even more memory overhead than a regular HashMap though.


Regards,
Maciej



dave
(hy...@apple.com)

On Oct 29, 2009, at 4:57 PM, Yaar Schnitman wrote:

I encountered a similar (potential) performance problem with style  
properties (see CSSMutableStyleDeclaration::findPropertyWithId),  
which are stored in an unordered vector too.


A potential solution would be to create a HashMap only for  
elements / style properties with more than K (5+?) attributes,  and  
only when they are first accessed. Such a hashmap will not replace  
the vector, but just provide an index to it.


On Thu, Oct 29, 2009 at 2:33 PM, Darin Adler  wrote:
On Oct 29, 2009, at 2:32 PM, Darin Adler wrote:

On Oct 29, 2009, at 2:30 PM, Jens Alfke wrote:

 Is there any reason this couldn't be optimized to use a HashMap

Memory consumption is much greater.

or at least binary search?

Would make lookups faster but parsing slower.

I forgot to mention:

I believe the common case for attributes is a very small number of  
attributes. Having one element with many attributes is quite  
uncommon. This is one consideration when making improvements and  
optimizations here. Making sure the pathological case is not  
terribly slow is good, but we also want the normal case to be super- 
fast.


   -- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Performance of NamedAttrMap

[Maciej Stachowiak]

On Oct 29, 2009, at 2:30 PM, Jens Alfke wrote:

I was looking at the performance of Element.getAttribute(), and I  
see that NamedAttrMap, which actually stores the attributes, is  
implemented as an unsorted array. This makes looking up an attribute  
an O(n) operation. Is there any reason this couldn't be optimized to  
use a HashMap, or at least binary search?


(I thought the answer might be that the order of attributes is  
significant; but I just checked the DOM spec, and NamedNodeMap is  
explicitly unordered.)


By far the most common case is that Elements have relatively few  
attributes (<6). This means that a hybrid strategy (unsorted array for  
a few attributes, HashMap for more than some threshold) might be  
successful:


a) With very few attributes, you minimize memory use, and the linear  
scan is not really slower than a hash lookup.
b) Because in practice very few elements have lots of attributes, the  
greater memory consumption of the HashMap will not be a significant  
cost on average.


The downside is that the likely inserts a branch into the common case,  
relative to what we have now, the benefit is that it's scalable to  
huge numbers of attribtues.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ThreadIdentifier abstraction is inefficient

[Anton Muhin]

ens,

Somewhat aside from ThreadIdentifier.

Actually, at least for now, there should be no invocations of
WTF::currentThread() at least for the renderer---everything should run
in the same thread.  Some time ago I got rid of those checks for Nodes
(see DOMDataStore::weakNodeCallback).  I didn't do the same for other
types of objects as they didn't show up in the profiles.

May you tell me which test(s) you run?

And, overall, some time ago I failed to build Chromium w/ symbols (to
use Shark), may you teach me how to do that?

Thanks a lot for investigation and
yours,
anton.

On Thu, Oct 29, 2009 at 11:31 PM, Jens Alfke  wrote:
> The implementation of the ThreadIdentifier abstraction (in
> wtf/ThreadingPthreads.cpp) is pretty inefficient. This makes calls like
> WTF::currentThread() a lot slower than you'd expect — that call is showing
> up as a hot spot in Chromium's JS/DOM bindings, believe it or not.
>
> I filed a bug on this: https://bugs.webkit.org/show_bug.cgi?id=30922
>
> My first suggestion is just to typedef ThreadIdentifier to pthread_t (if
> pthreads are in use) and avoid the need for a mapping altogether. Any reason
> this wouldn't be a good idea? (If not, I have two other suggestions in the
> bug report.)
>
> —Jens
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Performance of NamedAttrMap

[David Hyatt]

Experiment with .cssText and .innerHTML to see what I mean.

dave

On Oct 29, 2009, at 5:03 PM, David Hyatt wrote:

The order of the properties in both style declarations and in  
attribute maps is relevant for serialization that conforms to the  
original declared source order.


dave
(hy...@apple.com)

On Oct 29, 2009, at 4:57 PM, Yaar Schnitman wrote:

I encountered a similar (potential) performance problem with style  
properties (see CSSMutableStyleDeclaration::findPropertyWithId),  
which are stored in an unordered vector too.


A potential solution would be to create a HashMap only for  
elements / style properties with more than K (5+?) attributes,  and  
only when they are first accessed. Such a hashmap will not replace  
the vector, but just provide an index to it.


On Thu, Oct 29, 2009 at 2:33 PM, Darin Adler  wrote:
On Oct 29, 2009, at 2:32 PM, Darin Adler wrote:

On Oct 29, 2009, at 2:30 PM, Jens Alfke wrote:

 Is there any reason this couldn't be optimized to use a HashMap

Memory consumption is much greater.

or at least binary search?

Would make lookups faster but parsing slower.

I forgot to mention:

I believe the common case for attributes is a very small number of  
attributes. Having one element with many attributes is quite  
uncommon. This is one consideration when making improvements and  
optimizations here. Making sure the pathological case is not  
terribly slow is good, but we also want the normal case to be super- 
fast.


   -- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] about LGPL

[Darin Adler]

On Oct 29, 2009, at 7:17 AM, zheng shiju wrote:

I have port qt4.5 and webkit to an embedded linux board, and I edit  
qt and webkit source codes,
and I develop a TV look-feel application and based on the edit qt4.5  
and webkit , it is commercial.

so ,I must let my application following LGPL?


This mailing list is for discussing development of WebKit. If you’re  
just using WebKit and not contributing, the right place to ask  
questions is webkit-help.


It’s likely people won’t give you legal advice. Here’s about all I  
feel comfortable saying. You need to adhere to the license of the code  
you’re using. WebKit code is covered by LGPL- and BSD-style licenses.  
One thing you will definitely need to do is to make the source code  
with your modifications available.


-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Performance of NamedAttrMap

[David Hyatt]

The order of the properties in both style declarations and in  
attribute maps is relevant for serialization that conforms to the  
original declared source order.


dave
(hy...@apple.com)

On Oct 29, 2009, at 4:57 PM, Yaar Schnitman wrote:

I encountered a similar (potential) performance problem with style  
properties (see CSSMutableStyleDeclaration::findPropertyWithId),  
which are stored in an unordered vector too.


A potential solution would be to create a HashMap only for  
elements / style properties with more than K (5+?) attributes,  and  
only when they are first accessed. Such a hashmap will not replace  
the vector, but just provide an index to it.


On Thu, Oct 29, 2009 at 2:33 PM, Darin Adler  wrote:
On Oct 29, 2009, at 2:32 PM, Darin Adler wrote:

On Oct 29, 2009, at 2:30 PM, Jens Alfke wrote:

 Is there any reason this couldn't be optimized to use a HashMap

Memory consumption is much greater.

or at least binary search?

Would make lookups faster but parsing slower.

I forgot to mention:

I believe the common case for attributes is a very small number of  
attributes. Having one element with many attributes is quite  
uncommon. This is one consideration when making improvements and  
optimizations here. Making sure the pathological case is not  
terribly slow is good, but we also want the normal case to be super- 
fast.


   -- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Performance of NamedAttrMap

[Yaar Schnitman]

I encountered a similar (potential) performance problem with style
properties (see CSSMutableStyleDeclaration::findPropertyWithId), which are
stored in an unordered vector too.

A potential solution would be to create a HashMap only for elements / style
properties with more than K (5+?) attributes,  and only when they are first
accessed. Such a hashmap will not replace the vector, but just provide an
index to it.

On Thu, Oct 29, 2009 at 2:33 PM, Darin Adler  wrote:

> On Oct 29, 2009, at 2:32 PM, Darin Adler wrote:
>
>  On Oct 29, 2009, at 2:30 PM, Jens Alfke wrote:
>>
>>   Is there any reason this couldn't be optimized to use a HashMap
>>>
>>
>> Memory consumption is much greater.
>>
>>  or at least binary search?
>>>
>>
>> Would make lookups faster but parsing slower.
>>
>
> I forgot to mention:
>
> I believe the common case for attributes is a very small number of
> attributes. Having one element with many attributes is quite uncommon. This
> is one consideration when making improvements and optimizations here. Making
> sure the pathological case is not terribly slow is good, but we also want
> the normal case to be super-fast.
>
>-- Darin
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Implementing WebTiming as a part of HTML5

[Pavel Feldman]

Please see inline.

Thanks
Pavel

On Thu, Oct 29, 2009 at 11:12 PM, Darin Adler  wrote:
> Has there been any discussion of or feedback about the web timing proposal?
>

Not much of feedback yet.

> Would WebKit’s implementation of this be the first one?
>

Variation of this is supported in Chromium.

> Is someone planning on building a benchmark that uses this new feature to
> evaluate browser speed?
>

I am not aware of such plans. The idea is that web masters can get a
clue on user-perceived client side latency, especially related to the
initial loads and redirects.

>    -- Darin
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Performance of NamedAttrMap

[Darin Adler]

On Oct 29, 2009, at 2:32 PM, Darin Adler wrote:


On Oct 29, 2009, at 2:30 PM, Jens Alfke wrote:


 Is there any reason this couldn't be optimized to use a HashMap


Memory consumption is much greater.


or at least binary search?


Would make lookups faster but parsing slower.


I forgot to mention:

I believe the common case for attributes is a very small number of  
attributes. Having one element with many attributes is quite uncommon.  
This is one consideration when making improvements and optimizations  
here. Making sure the pathological case is not terribly slow is good,  
but we also want the normal case to be super-fast.


-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Performance of NamedAttrMap

[Darin Adler]

On Oct 29, 2009, at 2:30 PM, Jens Alfke wrote:


 Is there any reason this couldn't be optimized to use a HashMap


Memory consumption is much greater.


or at least binary search?


Would make lookups faster but parsing slower.

(I thought the answer might be that the order of attributes is  
significant; but I just checked the DOM spec, and NamedNodeMap is  
explicitly unordered.)


The DOM specification is not what matters here. Behavior of actual  
browsers is what determines website compatibility. So you will need to  
do more research on that.


I think there could be some real room for improvement here, but also  
plenty of opportunity to unwittingly make things worse.


-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Performance of NamedAttrMap

[Jens Alfke]

I was looking at the performance of Element.getAttribute(), and I see  
that NamedAttrMap, which actually stores the attributes, is  
implemented as an unsorted array. This makes looking up an attribute  
an O(n) operation. Is there any reason this couldn't be optimized to  
use a HashMap, or at least binary search?


(I thought the answer might be that the order of attributes is  
significant; but I just checked the DOM spec, and NamedNodeMap is  
explicitly unordered.)


—Jens___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ThreadIdentifier abstraction is inefficient

[Alexey Proskuryakov]

29.10.2009, в 13:31, Jens Alfke написал(а):


I filed a bug on this: https://bugs.webkit.org/show_bug.cgi?id=30922

My first suggestion is just to typedef ThreadIdentifier to pthread_t  
(if pthreads are in use) and avoid the need for a mapping  
altogether. Any reason this wouldn't be a good idea? (If not, I have  
two other suggestions in the bug report.)


For those following along at home, this has been duped to , which already has some interesting discussion, and will  
undoubtedly have more.


- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] ThreadIdentifier abstraction is inefficient

[Jens Alfke]

The implementation of the ThreadIdentifier abstraction (in wtf/ 
ThreadingPthreads.cpp) is pretty inefficient. This makes calls like  
WTF::currentThread() a lot slower than you'd expect — that call is  
showing up as a hot spot in Chromium's JS/DOM bindings, believe it or  
not.


I filed a bug on this: https://bugs.webkit.org/show_bug.cgi?id=30922

My first suggestion is just to typedef ThreadIdentifier to pthread_t  
(if pthreads are in use) and avoid the need for a mapping altogether.  
Any reason this wouldn't be a good idea? (If not, I have two other  
suggestions in the bug report.)


—Jens
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Implementing WebTiming as a part of HTML5

[Darin Adler]

Has there been any discussion of or feedback about the web timing  
proposal?


Would WebKit’s implementation of this be the first one?

Is someone planning on building a benchmark that uses this new feature  
to evaluate browser speed?


-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why are PassRefPtr<>s used as function parameters?

[Darin Adler]

On Oct 29, 2009, at 12:57 PM, Drew Wilson wrote:

HTMLCollection() keeps a reference to the object, so you can't  
safely pass in just a raw pointer.


Good point, but strictly speaking that’s not true.

It’s always safe to pass a raw pointer. The PassRefPtr type for the  
argument is solely about optimization, not safety or correctness.


I see what you mean, though. HTMLCollection’s constructor does take a  
PassRefPtr so it would be OK to have HTMLNamedCollection be consistent  
with this. Although there’s no realistic chance the document will be a  
just-created object, so it’s not a great practical optimization.



Since HTMLCollection keeps it around, you'd have to do the ref anyway.


Unfortunately, the get() inside the HTMLNameCollection’s constructor  
that is needed so we can call nameCollectionInfo with the same  
document pointer means that we do an extra round of reference count  
churn. And there’s no obvious way to rewrite it to eliminate that. So  
the PassRefPtr type on HTMLNameCollection’s constructor’s document  
argument currently does no good and a bit of harm.


-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why are PassRefPtr<>s used as function parameters?

[Drew Wilson]

In this case, HTMLCollection() keeps a reference to the object, so you can't
safely pass in just a raw pointer. Since HTMLCollection keeps it around,
you'd have to do the ref anyway.

-atw

On Tue, Oct 27, 2009 at 10:55 AM, Jens Alfke  wrote:

> Looking at how refcounting is implemented in WebCore, I was surprised to
> find that there are a lot of functions/methods that take PassRefPtr<>s as
> parameters instead of regular pointers to those objects. I can't see any
> benefit to this, and it adds the overhead of a ref() and deref() at every
> call-site.
>
> For example in HTMLNameCollection.h:
>  HTMLNameCollection(PassRefPtr, CollectionType, const String&
> name);
>
> Why shouldn't this be
>  HTMLNameCollection(Document*, CollectionType, const String& name);
> ?
>
> The use of PassRefPtr instead of RefPtr here also seems prone to trouble,
> since inside the implementation of the method it could end up unexpectedly
> clearing the parameter:
>  HTMLNameCollection::HTMLNameCollection(Document* doc,  {
>Ref otherDoc = doc; // This sets doc to NULL!
>doc->something(); // CRASH
> }
>
> I ran across this while trying to track down a reference leak of a Document
> object. As one of my last resorts I set a watchpoint on the object's
> m_refcount to see who refs/derefs it; but I had to give up because so many
> method calls, including the one above, keep constantly twiddling the
> refcount while passing the Document as a parameter.
>
> —Jens
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Why are PassRefPtr<>s used as function parameters?

[Darin Adler]

On Oct 27, 2009, at 10:55 AM, Jens Alfke wrote:

Looking at how refcounting is implemented in WebCore, I was  
surprised to find that there are a lot of functions/methods that  
take PassRefPtr<>s as parameters instead of regular pointers to  
those objects. I can't see any benefit to this, and it adds the  
overhead of a ref() and deref() at every call-site.


Have you read the RefPtr document? It is at .


Only functions that take ownership of the passed-in objects should  
take PassRefPtr. This makes it so we can optimally handle the case  
where that object was just created and lets us hand off the reference  
instead of having to do a round of reference count thrash. If the  
function is going to be storing the value in a RefPtr, then the  
PassRefPtr does not introduce any reference count thrash even if the  
passed in object was not just created.


It’s wrong for the HTMLNameCollection constructor to take a PassRefPtr  
for its document argument because it doesn’t take ownership of the  
document. So that one is definitely a mistake.


It is true that PassRefPtr arguments can be tricky as you mentioned  
and the RefPtr document also mentions.


-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] DEFINE_STATIC_LOCAL

[Eric Seidel]

Yes.
https://bugs.webkit.org/show_bug.cgi?id=27980#c44

On Thu, Oct 29, 2009 at 12:13 PM, Yong Li  wrote:
> I just noticed the following code:
>
> #else
> #define DEFINE_STATIC_LOCAL(type, name, arguments) \
>     static type& name = *new type arguments
> #endif
>
> Is there any reason of doing this? For example, we want to prevent dtors of
> all static objects from being called?
>
> Best regards,
>
> Yong Li
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] about LGPL

[zheng shiju]

Hi:

I have port qt4.5 and webkit to an embedded linux board, and I edit qt and
webkit source codes,
and I develop a TV look-feel application and based on the edit qt4.5 and
webkit , it is commercial.
so ,I must let my application following LGPL?

thanks.

bell
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Why are PassRefPtr<>s used as function parameters?

[Jens Alfke]

Looking at how refcounting is implemented in WebCore, I was surprised  
to find that there are a lot of functions/methods that take  
PassRefPtr<>s as parameters instead of regular pointers to those  
objects. I can't see any benefit to this, and it adds the overhead of  
a ref() and deref() at every call-site.


For example in HTMLNameCollection.h:
  HTMLNameCollection(PassRefPtr, CollectionType, const  
String& name);


Why shouldn't this be
  HTMLNameCollection(Document*, CollectionType, const String& name);
?

The use of PassRefPtr instead of RefPtr here also seems prone to  
trouble, since inside the implementation of the method it could end up  
unexpectedly clearing the parameter:

  HTMLNameCollection::HTMLNameCollection(Document* doc,  {
Ref otherDoc = doc; // This sets doc to NULL!
doc->something(); // CRASH
}

I ran across this while trying to track down a reference leak of a  
Document object. As one of my last resorts I set a watchpoint on the  
object's m_refcount to see who refs/derefs it; but I had to give up  
because so many method calls, including the one above, keep constantly  
twiddling the refcount while passing the Document as a parameter.


—Jens
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Implementing WebTiming as a part of HTML5

[Pavel Feldman]

I've been asked to look at the WebTiming proposal wrt implementing it in
WebKit. Any objections / suggestions or hints? Please find proposal brief
below.

Pavel

<< Pasting proposal brief below >>

User latency is an important quality benchmark for Web Applications. While
JavaScript-based mechanisms can provide comprehensive instrumentations for user
latency measurements within an application, in many cases, they are unable to
provide a complete end-to-end latency picture.

For example, the following Javascript shows the time it take to fully load a
page:

[webkit-dev] DEFINE_STATIC_LOCAL

[Yong Li]

I just noticed the following code:

#else
#define DEFINE_STATIC_LOCAL(type, name, arguments) \
static type& name = *new type arguments
#endif

Is there any reason of doing this? For example, we want to prevent dtors of
all static objects from being called?

Best regards,

Yong Li
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] How to zoom and move the selected node to center-screen ?

[pattin.shieh]

I am making a brower,by using webkit.I want make the browser support like
following description:
1).User click a editor;
2).Page zoom to 150% and auto scroll the view,let the eidtor(node) in
the center of the view;
4)Pop up the input window;
5).user easily enter text.

I wondering where to add the code, can somebody tell me?
Is it the best way or right? If let the webview catch the click-message and
then m_frame->setZoomFactor and frame->view()->scroll ? And ,how to catch
the click message?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev