WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
125827
Implement an ordered multimap in WTF
https://bugs.webkit.org/show_bug.cgi?id=125827
Summary
Implement an ordered multimap in WTF
Myles C. Maxfield
Reported
2013-12-16 19:50:44 PST
Implement an ordered multimap in WTF
Attachments
Patch
(12.75 KB, patch)
2013-12-16 19:54 PST
,
Myles C. Maxfield
no flags
Details
Formatted Diff
Diff
Patch
(12.75 KB, patch)
2013-12-16 21:15 PST
,
Myles C. Maxfield
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Myles C. Maxfield
Comment 1
2013-12-16 19:54:15 PST
Created
attachment 219387
[details]
Patch
Myles C. Maxfield
Comment 2
2013-12-16 21:15:58 PST
Created
attachment 219393
[details]
Patch
Geoffrey Garen
Comment 3
2013-12-16 21:49:20 PST
Comment on
attachment 219393
[details]
Patch Our typical strategy for keyed collections in WebKit is to use a hash table. The reason is that it is faster. Did you test the performance of this data structure? Did you compare it to the performance of a simple hash table, in which the values are vectors or linked lists? I'm hoping you did, but your ChangeLog doesn't contain any performance information, so I think you didn't. Our typical strategy for memory management is to use smart pointers. The reason is that raw pointers leak and crash. Did you consider unique_ptr with move semantics or some other smart pointer solution instead of manual new and delete?
Myles C. Maxfield
Comment 4
2013-12-17 10:50:02 PST
Clearly a hash table is faster than a binary tree for the operations it supports; however, I am working on a patch (
https://bugs.webkit.org/show_bug.cgi?id=125477
) that needs to iterate over the items in a map in increasing key order, which a hashmap doesn't support. I would have used a RedBlackTree directly, but I need to store multiple key-value pairs with the same key in this data structure. That led me to use a RedBlackTree of DoublyLinkedLists. Another reason I cannot use a HashTable is that I need to keep multiple iterators into this data structure, even while other keys value pairs are being added and removed, which HashTable doesn't support (it's add() function calls invalidateIterators()). I originally was using std::multimap for my work, but was told to use WTF types instead, so I had to create this class. I did not measure the performance, because I do not have anything to compare performance numbers against (because there is no other class in WTF with similar semantics). I used new and delete because they are the best fit for the existing base classes for RedBlackTree<>::Node and DoublyLinkedListNode<>. RedBlackTree<>::Node declares it's own left and right pointers as raw pointers; I could declare my own overriding left and right OwnPtr<>s, but that would end up with essentially an entirely new Node type and no code reuse with the existing Node class. I think making this new Node type is fine, but I think it belongs in RedBlackTee.h, which probably should be in another patch. Should I do this, or keep it as it is? For the DoublyLinkedListNode case, my subclass keeps the pointer members, however operations on the list itself (like append() and tail()) deal with raw pointers. Because DoublyLinkedList itself calls the assignment operator on the previous and next pointers, without using adoptRef, I would end up having to re-implement an entirely new LinkedList implementation.
Anders Carlsson
Comment 5
2013-12-17 10:58:47 PST
I think a sorted vector would be fine here because the IOSurface management code is going to dwarf the cache management code here anyway.
Geoffrey Garen
Comment 6
2013-12-17 11:30:25 PST
(In reply to
comment #4
)
> Clearly a hash table is faster than a binary tree for the operations it supports; however, I am working on a patch (
https://bugs.webkit.org/show_bug.cgi?id=125477
) that needs to iterate over the items in a map in increasing key order, which a hashmap doesn't support.
I see. This sounds like a red flag. If we're willing to pay the cost of iterating the data structure, we can probably use a much simpler data structure. If we're not willing to pay the cost of iterating the data structure, we need a different design.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug