google-sparsehash Google Group

Re: erase doesn't return an iterator (thankfully)

sjack...@gmail.com (ShaunJ) — Tue, 10 Nov 2009 18:54:09 UT

Thanks for the tip. It is a usable workaround, but it's not ideal. I
dislike having to hurt the runtime of the typical case to prevent
disaster in the worst case.

Cheers,
Shaun

Re: erase doesn't return an iterator (thankfully)

sjack...@gmail.com (ShaunJ) — Tue, 10 Nov 2009 18:48:35 UT

++it is not constant time for sparse_hash_set in the worst case, where
it is
O(bucket_count() - size())

For my application, to prevent resizing the hash table, I set the
number of buckets to an appropriate size for the data set before
starting the algorithm. However, if the data set is sorted, it inserts

Re: erase doesn't return an iterator (thankfully)

csilv...@google.com (Craig Silverstein) — Mon, 09 Nov 2009 23:29:40 UT

btw, I saw your post about this at
[link]
In the situation you describe, you can get around the cost of it++ by
calling erase(*it) instead of erase(it). It means an extra hash, but
if that's faster than the ++it it may be a better choice.

Re: erase doesn't return an iterator (thankfully)

csilv...@google.com (Craig Silverstein) — Mon, 09 Nov 2009 21:10:52 UT

I should probably mirror unordered_set, shouldn't I? In
sparse_hash_set, ++ is constant-time, so there's no reason not to
support it, even if the spec doesn't require it. For dense_hash_set,
it's a different story.
I agree with the "Toronto consensus" that if needed, the iterator
could be its own proxy. I may do that for dense_hash_map; it adds a

erase doesn't return an iterator (thankfully)

sjack...@gmail.com (ShaunJ) — Mon, 09 Nov 2009 19:38:14 UT

The C++ standard says that unordered_set::erase returns an iterator to
the next element:
[link]

erase should be O(1) and in the worst case O(size()), whereas, for
most hash table implementations ++it is O(bucket_count()). In
particular, if the has table only has one element, removing it

Re: Issue 45 in google-sparsehash: Can't compile on debian lenny i386

codesite-nore...@google.com — Thu, 05 Nov 2009 18:00:20 UT

Updates:
Status: Invalid
Comment #1 on issue 45 by csilvers: Can't compile on debian lenny i386
[link]
Looks like you filed this under the wrong project. Can you re-file under
google-perftools?

Issue 45 in google-sparsehash: Can't compile on debian lenny i386

codesite-nore...@google.com — Thu, 05 Nov 2009 17:55:13 UT

Status: New
Owner: ----

New issue 45 by fredericsmailbox: Can't compile on debian lenny i386
[link]

Source code just updated and can't compile it on Debian Lenny i386
(./configure --enable-minimal and without):

In file included from src/symbolize.cc:37:

Re: help with Visual C++

yilia...@gmail.com (Yi) — Thu, 05 Nov 2009 14:12:03 UT

Thanks Craig. It worked after I copied the directories to my project.
And I have to change

Re: Insert and delete near the high watermark

csilv...@google.com (Craig Silverstein) — Wed, 04 Nov 2009 22:16:17 UT

Interestingly, someone else had this exact same problem recently.
I've checked in a fix, but not yet pushed it to the svn. I will try
to get to that sometime this week.
In the meantime, here's the fix, which I'm afraid you'll have to apply
manually: add this code after the 'const size_type resize_to' line you

Insert and delete near the high watermark

sjack...@gmail.com (ShaunJ) — Wed, 04 Nov 2009 21:58:08 UT

When the number of elements in the table is exactly at the high water
mark (num_elements - num_deleted == bucket_count() *
enlarge_resize_percent) and there's one deleted element (num_deleted
== 1), inserting a new element will cause the table to clean itself
of deleted items but not enlarge itself, because

Re: sparsehash can shrink even with min_load_factor(0)

sjack...@gmail.com (ShaunJ) — Wed, 04 Nov 2009 19:45:04 UT

Great. Thanks, Craig.

Re: sparsehash can shrink even with min_load_factor(0)

csilv...@google.com (Craig Silverstein) — Wed, 04 Nov 2009 18:44:29 UT

Never mind, I looked at the code more closely and see that your fix is
right, and my objection is wrong. I'll do a bit of testing, and look
to get this into the next release.
craig

Re: sparsehash can shrink even with min_load_factor(0)

csilv...@google.com (Craig Silverstein) — Wed, 04 Nov 2009 18:39:26 UT

Insert causing a shrink is desired behavior: it's because we never
resize a hashtable on delete (in order to preserve iterators an
pointers while deleting).
So I think your patch would mean, in effect, we never shrink the
hashtable regardless of the min_load_factor, which isn't ideal.
I think, though, it makes sense to add a check there that never

Re: sparsehash can shrink even with min_load_factor(0)

sjack...@gmail.com (ShaunJ) — Wed, 04 Nov 2009 18:20:44 UT

Hi Craig,

Here's a patch that prevents sparse_hashtable from reducing the number
of buckets if it's resizing `just to get rid of all the "deleted"
buckets that are clogging up the hashtable.' Currently, inserting an
element can cause the number of buckets to shrink.

Cheers,
Shaun

2009-11-04 Shaun Jackman <sjack...@gmail.com>

Re: sparsehash can shrink even with min_load_factor(0)

sjack...@gmail.com (ShaunJ) — Wed, 04 Nov 2009 17:41:47 UT

...

Hi Craig,

sparse_hashtable can shrink even with min_load_factor(0); I've seen
this in action. If the number of deleted items make up more than half
the number of elements in the table, the logic of resize_delta can in
fact choose a smaller number of buckets than were allocated
previously. It's this behaviour that I'm trying to prevent.