StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
2851509
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2010-05-17T18:05:27.297
FavoriteCount
0
LastActivityDate
2010-05-17T18:05:27.297
LastEditDate
LastEditorUserId
0
OwnerUserId
147192
ParentId
772192
PostTypeId
2
Score
3
ViewCount
0
LastEditorDisplayName
text
Body
The obvious question is why would you want to actually use a hash ? I understand the issue with <code>map</code> / <code>set</code> for performance critical code, indeed those containers are not very cache friendly because the items might be allocated at very different memory locations. As KeithB suggested (I won't comment on using the binary representation since nothing guarantees that 2 ids have the same binary representation after all...), using a sorted <code>vector</code> can speed up the code in case there is very few items. Sorted vectors / deques are much more cache-friendly, however they suffer from a O(N) complexity on insert/erase because of the copying involved. Once you reach a couple hundreds threads (never seen that many by the way), it could hurt. There is however, a data structure that tries to associate the benefits from maps and sorted vectors: the <a href="http://en.wikipedia.org/wiki/B%2B_tree" rel="nofollow noreferrer">B+Tree</a>. You can view it as a map for which each node would contain more than one element (in sorted order). Only the leaf nodes are used. To get some more performance you can: <ul> <li>Link the leaves linearly: ie the root caches a pointer to the first and last leaf and the leaves are interconnected themselves, so that linear travel completely bypass the interal nodes.</li> <li>Cache the last accessed leaf in the root, after all it's likely that'll also be the next one accessed.</li> </ul> The asymptotic performances are the same than for the map, because it's implemented as a Balanced Binary Tree, but because the values are packed in groups, you're code can become faster by a constant. The real difficulty is to tailor the size of each "bucket", you'll need some profiling for that so it would be better if your implementation allowed some customization there (as it will depend on the architecture on which the code is executed).
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POtr1::hash for boost::thread::id?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USMatthieu M.
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.