History log of /src/lib/libc/stdlib/hcreate.3 (Results 1 – 25 of 60)
Revision Date Author Comments
# fa9896e0 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

Remove $FreeBSD$: two-line nroff pattern

Remove /^\.\\"\n\.\\"\s*\$FreeBSD\$$\n/


# fa9896e0 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

Remove $FreeBSD$: two-line nroff pattern

Remove /^\.\\"\n\.\\"\s*\$FreeBSD\$$\n/


# 1a36faad 11-Feb-2017 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r313301 through r313643.


# a678f779 07-Feb-2017 Enji Cooper <ngie@FreeBSD.org>

MFhead@r313380


# d5f154d3 07-Feb-2017 Enji Cooper <ngie@FreeBSD.org>

hcreate(3): fix the ERRORS section and bump .Dd

- Add missing comma between functions that trigger ENOMEM error.
- Fix the description for ESRCH. The action that triggers this error is
FIND, not S

hcreate(3): fix the ERRORS section and bump .Dd

- Add missing comma between functions that trigger ENOMEM error.
- Fix the description for ESRCH. The action that triggers this error is
FIND, not SEARCH (SEARCH does not exist).

MFC after: 1 week
Sponsored by: Dell EMC Isilon

show more ...


# b626f5a7 04-Jan-2016 Glen Barber <gjb@FreeBSD.org>

MFH r289384-r293170

Sponsored by: The FreeBSD Foundation


# 4c78ed5a 28-Dec-2015 Bjoern A. Zeeb <bz@FreeBSD.org>

Mfh r292839


# 2747eff1 27-Dec-2015 Ed Schouten <ed@FreeBSD.org>

Replace implementation of hsearch() by one that scales.

Traditionally the hcreate() function creates a hash table that uses
chaining, using a fixed user-provided size. The problem with this
approach

Replace implementation of hsearch() by one that scales.

Traditionally the hcreate() function creates a hash table that uses
chaining, using a fixed user-provided size. The problem with this
approach is that this often either wastes memory (table too big) or
yields bad performance (table too small). For applications it may not
always be easy to estimate the right hash table size. A fixed number
only increases performance compared to a linked list by a constant
factor.

This problem can be solved easily by dynamically resizing the hash
table. If the size of the hash table is at least doubled, this has no
negative on the running time complexity. If a dynamically sized hash
table is used, we can also switch to using open addressing instead of
chaining, which has the advantage of just using a single allocation for
the entire table, instead of allocating many small objects.

Finally, a problem with the existing implementation is that its
deterministic algorithm for hashing makes it possible to come up with
fixed patterns to trigger an excessive number of collisions. We can
easily solve this by using FNV-1a as a hashing algorithm in combination
with a randomly generated offset basis.

Measurements have shown that this implementation is about 20-25% faster
than the existing implementation (even if the existing implementation is
given an excessive number of buckets). Though it allocates more memory
through malloc() than the old implementation (between 4-8 pointers per
used entry instead of 3), process memory use is similar to the old
implementation as if the estimated size was underestimated by a factor
10. This is due to the fact that malloc() needs to perform less
bookkeeping.

Reviewed by: jilles, pfg
Obtained from: https://github.com/NuxiNL/cloudlibc
Differential Revision: https://reviews.freebsd.org/D4644

show more ...


# 246e7a2b 02-Sep-2014 Neel Natu <neel@FreeBSD.org>

IFC @r269962

Submitted by: Anish Gupta (akgupt3@gmail.com)


# ee7b0571 19-Aug-2014 Simon J. Gerraty <sjg@FreeBSD.org>

Merge head from 7/28


# 1b833d53 13-Aug-2014 Alexander V. Chernikov <melifaro@FreeBSD.org>

Sync to HEAD@r269943.


# 9823a90c 21-Jul-2014 Pedro F. Giffuni <pfg@FreeBSD.org>

Add re-entrant versions of the hash functions based on the GNU api.

While testing this I found a conformance issue in hdestroy()
that will be fixed in a subsequent commit.

Obtained from: NetBSD (hc

Add re-entrant versions of the hash functions based on the GNU api.

While testing this I found a conformance issue in hdestroy()
that will be fixed in a subsequent commit.

Obtained from: NetBSD (hcreate.c, CVS Rev. 1.7)

show more ...


# 1a36faad 11-Feb-2017 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r313301 through r313643.


# a678f779 07-Feb-2017 Enji Cooper <ngie@FreeBSD.org>

MFhead@r313380


# d5f154d3 07-Feb-2017 Enji Cooper <ngie@FreeBSD.org>

hcreate(3): fix the ERRORS section and bump .Dd

- Add missing comma between functions that trigger ENOMEM error.
- Fix the description for ESRCH. The action that triggers this error is
FIND, not S

hcreate(3): fix the ERRORS section and bump .Dd

- Add missing comma between functions that trigger ENOMEM error.
- Fix the description for ESRCH. The action that triggers this error is
FIND, not SEARCH (SEARCH does not exist).

MFC after: 1 week
Sponsored by: Dell EMC Isilon

show more ...


# b626f5a7 04-Jan-2016 Glen Barber <gjb@FreeBSD.org>

MFH r289384-r293170

Sponsored by: The FreeBSD Foundation


# 4c78ed5a 28-Dec-2015 Bjoern A. Zeeb <bz@FreeBSD.org>

Mfh r292839


# 2747eff1 27-Dec-2015 Ed Schouten <ed@FreeBSD.org>

Replace implementation of hsearch() by one that scales.

Traditionally the hcreate() function creates a hash table that uses
chaining, using a fixed user-provided size. The problem with this
approach

Replace implementation of hsearch() by one that scales.

Traditionally the hcreate() function creates a hash table that uses
chaining, using a fixed user-provided size. The problem with this
approach is that this often either wastes memory (table too big) or
yields bad performance (table too small). For applications it may not
always be easy to estimate the right hash table size. A fixed number
only increases performance compared to a linked list by a constant
factor.

This problem can be solved easily by dynamically resizing the hash
table. If the size of the hash table is at least doubled, this has no
negative on the running time complexity. If a dynamically sized hash
table is used, we can also switch to using open addressing instead of
chaining, which has the advantage of just using a single allocation for
the entire table, instead of allocating many small objects.

Finally, a problem with the existing implementation is that its
deterministic algorithm for hashing makes it possible to come up with
fixed patterns to trigger an excessive number of collisions. We can
easily solve this by using FNV-1a as a hashing algorithm in combination
with a randomly generated offset basis.

Measurements have shown that this implementation is about 20-25% faster
than the existing implementation (even if the existing implementation is
given an excessive number of buckets). Though it allocates more memory
through malloc() than the old implementation (between 4-8 pointers per
used entry instead of 3), process memory use is similar to the old
implementation as if the estimated size was underestimated by a factor
10. This is due to the fact that malloc() needs to perform less
bookkeeping.

Reviewed by: jilles, pfg
Obtained from: https://github.com/NuxiNL/cloudlibc
Differential Revision: https://reviews.freebsd.org/D4644

show more ...


# 246e7a2b 02-Sep-2014 Neel Natu <neel@FreeBSD.org>

IFC @r269962

Submitted by: Anish Gupta (akgupt3@gmail.com)


# ee7b0571 19-Aug-2014 Simon J. Gerraty <sjg@FreeBSD.org>

Merge head from 7/28


# 1b833d53 13-Aug-2014 Alexander V. Chernikov <melifaro@FreeBSD.org>

Sync to HEAD@r269943.


# 9823a90c 21-Jul-2014 Pedro F. Giffuni <pfg@FreeBSD.org>

Add re-entrant versions of the hash functions based on the GNU api.

While testing this I found a conformance issue in hdestroy()
that will be fixed in a subsequent commit.

Obtained from: NetBSD (hc

Add re-entrant versions of the hash functions based on the GNU api.

While testing this I found a conformance issue in hdestroy()
that will be fixed in a subsequent commit.

Obtained from: NetBSD (hcreate.c, CVS Rev. 1.7)

show more ...


# a4bf5fb9 28-Apr-2010 Kirk McKusick <mckusick@FreeBSD.org>

Update to current version of head.


# aa12cea2 14-Apr-2010 Ulrich Spörlein <uqs@FreeBSD.org>

mdoc: order prologue macros consistently by Dd/Dt/Os

Although groff_mdoc(7) gives another impression, this is the ordering
most widely used and also required by mdocml/mandoc.

Reviewed by: ru
Appro

mdoc: order prologue macros consistently by Dd/Dt/Os

Although groff_mdoc(7) gives another impression, this is the ordering
most widely used and also required by mdocml/mandoc.

Reviewed by: ru
Approved by: philip, ed (mentors)

show more ...


# 5fd5badf 06-Jul-2008 Daniel Gerzo <danger@FreeBSD.org>

- This code was intially obtained from NetBSD, but it's missing licence
statement. Add the one from the current NetBSD version.
- Also bump a date to reflect my content changes I have done in previ

- This code was intially obtained from NetBSD, but it's missing licence
statement. Add the one from the current NetBSD version.
- Also bump a date to reflect my content changes I have done in previous
revision

Approved by: imp
MFC after: 3 days

show more ...


123