[webkit-dev] Performance of NamedAttrMap

Maciej Stachowiak mjs at apple.com
Thu Oct 29 15:27:40 PDT 2009


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
> (hyatt at 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 <darin at apple.com> 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 at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091029/08e1b3ae/attachment.html>


More information about the webkit-dev mailing list