summaryrefslogtreecommitdiffstats
path: root/lib/libc/stdlib/hcreate.c
Commit message (Collapse)AuthorAgeFilesLines
* Replace implementation of hsearch() by one that scales.ed2015-12-271-179/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix hdestroy() compliance issue.pfg2014-07-211-1/+0
| | | | | | | | | | | | | | | | | | | The hcreate(3) implementation and related functions we inherited from NetBSD used to free() the key value, something that is not supported by the standard implementation. This would cause a segmentation fault when attempting to run the examples from the opengroup and linux manpages. NetBSD has added non-standard calls to provide the previous behaviour but hdestroy is not very commonly used so at this time it seems excessive to bring those to FreeBSD. Bump the __FreeBSD_version as this is an ABI change. Reference: http://bugs.dragonflybsd.org/issues/1398 MFC after: 2 weeks
* Update license.pfg2014-07-211-7/+2
| | | | | | NetBSD has removed the advertisement clause from this file. Obtained from: NetBSD (CVS rev. 1,8)
* Add re-entrant versions of the hash functions based on the GNU api.pfg2014-07-211-29/+68
| | | | | | | 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)
* libc/stdlib: Minor cleanups to code originating in NetBSDpfg2014-07-151-3/+3
| | | | | | | Mostly ANSIfication and typos. Obtained from: NetBSD MFC after: 5 days
* - remove superfluous worddanger2008-07-061-3/+3
| | | | | | - remove contractions MFC after: 3 days
* Remove improper use of <namespace.h>deischen2002-06-271-1/+0
|
* Fix the style of the SCM ID's.obrien2002-03-221-1/+3
| | | | I believe have made all of libc .c's as consistent as possible.
* Add new, from scratch implementation of hsearch() et al that actually works.ru2001-05-151-0/+184
Obtained from: NetBSD MFC after: 1 month
OpenPOWER on IntegriCloud