summaryrefslogtreecommitdiff
path: root/hv.h
Commit message (Collapse)AuthorAgeFilesLines
* only fully calculate the stash (effective) name where neededTony Cook2022-11-181-9/+11
| | | | | | | | | gcc 12 was complaining that evaluating (somehekptr)->hek_key was always true in many places where HvNAME() or HvENAME() was being called in boolean context. Add new macros to check whether the names should be available and use those instead.
* Use HvHasAUX() rather than SvOOK() when operating on HVsPaul "LeoNerd" Evans2022-07-021-12/+12
|
* Create `HvHasAUX()` macroPaul "LeoNerd" Evans2022-07-021-1/+15
| | | | | | | | Gives a new name `SVphv_HasAUX` to the `SVf_OOK` flag, for use on HVs. For back-compatibility with existing code we'll have to continue to use the same bit position, at least for now. But at least code can use this new name to be clearer about its intent.
* perlintern: Make hv_fill internal, HvFILL its APIKarl Williamson2022-05-101-1/+7
| | | | HvFILL wraps hv_fill, with appropriate casting, so should be preferred.
* hv.* - disable unshared keys except when requestedYves Orton2022-04-191-0/+7
| | | | | | | | | This disables the new unshared hash key logic by default. People who wish to try it out can enable it at build time with -DPERL_USE_UNSHARED_KEYS_IN_LARGE_HASHES in the configure process.
* Heuristically turn off shared hash keys for larger hashesNicholas Clark2022-03-191-0/+7
| | | | | | The assumption is that large hashes (that are not objects or symbol tables) have keys that are not repeated in other hashes, hence (also) storing those keys in the shared string table is creating work without real benefit.
* Rename HVhek_UNSHARED to HVhek_NOTSHAREDNicholas Clark2022-03-191-4/+2
| | | | | | | | | | | | | | "HVhek_UNSHARED" marked unshared HEKs - allocated directly with malloc(), rather then from the shared string table, and released with free(). But *shared* HEKs (in the shared string table) are released by calling unshare_hek(), whilst unshared HEKs should never go near this. So rename them to "not shared", to avoid this confusion. Change their flag bit from 0x08 to 0x04 to remove a gap. 0x04 had previously been used to flag "REHASH", which was removed before v5.18.0 Move the definition of the macro HVhek_MASK from hv.h to hv.c
* Add 'ASSERT_IS_LITERAL' macroKarl Williamson2022-03-031-5/+5
| | | | | This is intended to make it obvious what this relatively obscure C construct is doing.
* Split the XPVHV body into two variants "normal" and "with aux"Nicholas Clark2021-10-111-1/+8
| | | | | | | | Default to the smaller body, and switch to the larger body if we need to allocate a C<struct xpvhv_aux> (eg need an iterator). This restores the previous small size optimisation for hashes used as objects.
* Delete the do_aux code from S_hsplit()Nicholas Clark2021-10-111-12/+0
| | | | | | | | This existed to handle automatically allocating an "aux" structure for larger hashes, to save a (large) reallocation if they needed to be iterated. Now that we no longer store the aux structure in the main hash array, we don't need to take this precaution.
* Inline the xhv_aux struct in the main hash bodyNicholas Clark2021-10-111-1/+2
| | | | | For now, memory for this structure is always allocated, even though it isn't always flagged as being present.
* Delete the macro XHvTOTALKEYS() which is unused and not in the API.Nicholas Clark2021-08-261-4/+1
| | | | | | | | | | | | | | | | XHvTOTALKEYS() was added in Dec 2001 as part of commit 8aacddc1ea3837f8: Tidied version of Jeffrey Friedl's <jfriedl@yahoo.com> restricted hashes - added delete of READONLY value inhibit & test for same - re-tabbed It's not part of the API, and not used by any code on CPAN. The last (and only) direct use was in Perl_hv_clear_placeholders(), and that was converted to HvTOTALKEYS() in May 2005 as part of commit 5d88ecd7e75b7174: Various HvPLACEHOLDERS() that should be HvPLACEHOLDERS_get() Hence "inline" the macro XHvTOTALKEYS() into the macro HvTOTALKEYS(), eliminating the only use of XHvTOTALKEYS().
* Convert code in mro_core.c to use hv_*hek() APIs where possible.Nicholas Clark2021-07-261-0/+3
| | | | | | | | Add a macro hv_existshek() to implement exists. The HEK-based macros are more efficient wrappers of hv_common() than the string/length/flags macros because they also pass in the pre-computed hash value (from the HEK). This avoids hv_common() needing to recalculate it.
* Make REFCOUNTED_HE_EXISTS available outside of coreLeon Timmermans2021-03-151-3/+1
| | | | This is needed to be able to define cophh_exists functions
* style: Detabify indentation of the C code maintained by the core.Michael G. Schwern2021-01-171-54/+54
| | | | | | | | | | | This just detabifies to get rid of the mixed tab/space indentation. Applying consistent indentation and dealing with other tabs are another issue. Done with `expand -i`. * vutil.* left alone, it's part of version. * Left regen managed files alone for now.
* autodoc.pl: Specify scn for single-purpose filesKarl Williamson2020-11-061-2/+0
| | | | | | | | Many of the files in perl are for one thing only, and hence their embedded documentation will be for that one thing. By creating a hash here of them, those files don't have to worry about what section that documentation goes under, and so it can be completely changed without affecting them.
* Fix return type in pod for HvNAMELEN_getKarl Williamson2020-09-281-1/+1
| | | | 37738dd69b1 set it incorrectly
* Note for Devel::PPPort HvNAME_get, HvNAMELEN_getKarl Williamson2020-09-051-0/+4
|
* Reorganize perlapiKarl Williamson2020-09-041-5/+1
| | | | | This uses a new organization of sections that I came up with. I asked for comments on p5p, but there were none.
* Change pod for macros that require "literal strings"Karl Williamson2019-09-021-2/+2
| | | | | Now that Devel::PPPort has the ability to handle these, we can loosen the syntax for clarity.
* Document HvFILLKarl Williamson2019-09-021-0/+10
|
* Fix apidoc macro entriesKarl Williamson2019-06-251-2/+2
| | | | | | | | | | This makes various fixes to the text that is used to generate the documentation. The dominant change is to add the 'n' flag to indicate that the macro takes no arguments. A couple should have been marked with a D (for deprecated) flag, and a couple were missing parameters, and a couple were missing return values. These were spotted by using Devel::PPPort on them.
* better document macros taking literal stringsZefram2017-11-121-4/+4
| | | | | | | | | | When giving a function-style prototype for a macro taking a literal string parameter, put a string literal in place of a type for that parameter. This goofy appearance makes it obvious that this isn't really a function, and clues the reader in that the parameter can't actually be an arbitrary expression of the right type. Also change the nonsensical "NUL-terminated literal string" to "literal string" to describe these parameters. Fixes [perl #116286].
* HvTOTALKEYS() takes a HV* as argumentSteffen Mueller2017-02-031-1/+1
| | | | | | | Incidentally, it currently works on SV *'s as well because there's an explicit cast after an SvANY. Let's not rely on that. This commit also removes a pointless const in a cast. Again. It takes an HV * as argument. Let's only change that if we have a strong reason to.
* Use cBOOL() instead of ? TRUE : FALSEDagfinn Ilmari Mannsåker2017-01-251-4/+2
| | | | Except under cpan/ and dist/
* fix hv.h build breakageDavid Mitchell2016-11-031-1/+0
| | | | The previous commit had a double closing comment (*/)
* add a comment about the properties of struct hekYves Orton2016-11-031-4/+10
|
* Revert "hv.h: rework HEK_FLAGS to a proper member in struct hek"Tony Cook2016-11-031-2/+3
| | | | | | | | This reverts commit d3148f758506efd28325dfd8e1b698385133f0cd. SV keys are stored as pointers in the key_key, on platforms with alignment requirements (such as PA-RISC) this resulted in bus errors early in the build.
* hv.h: rework HEK_FLAGS to a proper member in struct hekTodd Rinaldo2016-10-241-3/+2
| | | | | | | | | | | | | | | | | | | | | Move the store of HEK_FLAGS off the end of the allocated hek_key into the hek struct, simplifying access and providing clarity to the code. What is not clear is why Nicholas or perhaps Jarkko did not do this themselves. We use similar tricks elsewhere, so perhaps it was just continuing a tradition... One thought is that we often have do strcmp/memeq on these strings, and having their start be aligned might improve performance, wheras this patch changes them to be unaligned. If so perhaps we should just make flags a U32 and let the HEK's be larger. They are shared in PL_strtab, and are probably often sitting in malloc blocks that are sufficiently large enough that making them bigger would make no practical difference. (All of this is worth checking.) [with edits by Yves Orton]
* handy.h, hv.h: fixup hash s suffix macro definitions, move to hv.hYves Orton2016-10-191-0/+20
| | | | | | | | | | | | | For some reason s suffix macro definitions intended for handling constant string arguments were put into handy.h and not into hv.h. I think this is wrong, especially as the macro defintions have "drifted" and are not properly defined in terms the right base macros. Also we want to have such wrappers for the main hash functions, so move them all to hv.h, recode them properly in terms of the right base macros, and add support for the missing functions.
* Change scalar(%hash) to be the same as 0+keys(%hash)Yves Orton2016-06-221-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This subject has a long history see [perl #114576] for more discussion. https://rt.perl.org/Public/Bug/Display.html?id=114576 There are a variety of reasons we want to change the return signature of scalar(%hash). One is that it leaks implementation details about our associative array structure. Another is that it requires us to keep track of the used buckets in the hash, which we use for no other purpose but for scalar(%hash). Another is that it is just odd. Almost nothing needs to know these values. Perhaps debugging, but we have several much better functions for introspecting the internals of a hash. By changing the return signature we can remove all the logic related to maintaining and updating xhv_fill_lazy. This should make hot code paths a little faster, and maybe save some memory for traversed hashes. In order to provide some form of backwards compatibility we adds three new functions to the Hash::Util namespace: bucket_ratio(), num_buckets() and used_buckets(). These functions are actually implemented in universal.c, and thus always available even if Hash::Util is not loaded. This simplifies testing. At the same time Hash::Util contains backwards compatible code so that the new functions are available from it should they be needed in older perls. There are many tests in t/op/hash.t that are more or less obsolete after this patch as they test that xhv_fill_lazy is correctly set in various situations. However since we have a backwards compat layer we can just switch them to use bucket_ratio(%hash) instead of scalar(%hash) and keep the tests, just in case they are actually testing something not tested elsewhere.
* minor comment improvements in hv.h and scope.hDaniel Dragan2016-02-161-1/+2
| | | | | -perl doesn't use malloc, it uses Newx (per interp memory) -say what the return type is of SSNEW
* [perl #126410] keep the DESTROY cache in mro_metaTony Cook2016-02-081-0/+1
| | | | | | | | | | | | | We're already keeping destroy_gen there, so keep the CV there too. The previous implementation, introduced in 8c34e50d, kept the destroy method cache in the stash's stash, which broke B's SvSTASH method. Before that, the DESTROY method was cached in overload magic. A previous version of this patch didn't clear the destructor cache on a clone, which caused ext/XS-APItest/t/clone_with_stack.t to fail.
* perlapi: Clarify that a literal string must end in a NULKarl Williamson2016-02-031-4/+4
| | | | Some entries already had this. For those, it standardizes the text.
* perlapi use 'UTF-8' instead of variants of thatKarl Williamson2015-09-031-2/+2
|
* Various pods: Add C<> around many typed-as-is thingsKarl Williamson2015-09-031-1/+1
| | | | Removes 'the' in front of parameter names in some instances.
* perlapi, perlintern: Add L<> links to podKarl Williamson2015-09-031-2/+2
|
* Replace common Emacs file-local variables with dir-localsDagfinn Ilmari Mannsåker2015-03-221-6/+0
| | | | | | | | | | | | | | | | An empty cpan/.dir-locals.el stops Emacs using the core defaults for code imported from CPAN. Committer's work: To keep t/porting/cmp_version.t and t/porting/utils.t happy, $VERSION needed to be incremented in many files, including throughout dist/PathTools. perldelta entry for module updates. Add two Emacs control files to MANIFEST; re-sort MANIFEST. For: RT #124119.
* Change name of mro.cKarl Williamson2015-03-191-1/+1
| | | | | | | | | This is to prevent a conflict showing up on z/OS (os390) because this file's name is the same as one in /ext, and there are functions cross-referenced between them, and the loader on that platform can't deal with this. See http://nntp.perl.org/group/perl.perl5.porters/226612
* fix documentation of HeUTF8 return valueDavid Golden2014-04-041-1/+1
|
* hv.h: tweak comment about HvAUX preallocation for large hashesAaron Crane2014-03-201-1/+3
|
* Preallocate HvAUX() structures for large bucket arraysYves Orton2014-03-181-0/+10
| | | | | | | | | | | | The assumption is that the time/space tradeoff of not allocating the HvAUX() structure goes away for a large bucket array where the size of the allocated buffer is much larger than the nonallocated HvAUX() "extension". This should make keys() and each() on larger hashes faster, but still preserve the essence of the original space conservation, where the assumption is a lot of small hash based objects which will never be traversed.
* speed up (non)overloaded derefsDavid Mitchell2014-02-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider a class that has some minimal overloading added - e.g. to give pretty stringification of objects - but which *doesn't* overload dereference methods such as '@[]'. '%[]' etc. In this case, simple dereferencing, such as $obj->[0] or $obj->{foo} becomes much slower than if the object was blessed into a non-overloaded class. This is because every time a dereferencing is performed in pp_rv2av for example, the "normal" code path has to go through the full checking of: * is the stash into which the referent is blessed overloaded? If so, * retrieve the overload magic from the stash; * check whether the overload method cache has been invalidated and if so rebuild it; * check whether we are in the scope of 'no overloading', and if so is the current method disabled in this scope? * Is there a '@{}' or whatever (or 'nomethod') method in the cache? If not, then process the ref as normal. That's a lot of extra overhead to decide that an overloaded method doesn't in fact need to be called. This commit adds a new flag to the newish xhv_aux_flags field, HvAUXf_NO_DEREF, which signals that the overloading of this stash contains no deref (nor 'nomethod') overloaded methods. Thus a quick check for this flag in the common case allows us to short-circuit all the above checks except the first one. Before this commit, a simple $obj->[0] was about 40-50% slower if the class it was blessed into was overloaded (but didn't have deref methods); after the commit, the slowdown is 0-10%. (These timings are very approximate, given the vagaries of nano benchmarks.)
* gv_check(): use aux flag rather than IsCOWDavid Mitchell2014-02-281-0/+2
| | | | | | | | | | Currently the SVf_IsCOW flag doesn't have any meaning for HVs, except that it is used in the specific case of gv_check() to temporarily mark a stash as being scanned. Since stashes will have the HV_AUX fields, we can use a flags bit in the new xhv_aux_flags field instead. This then potentially frees up the SVf_IsCOW for use as a new general flag bit for *all* HVs (including non-stash ones).
* add aux_flags field to HVs with aux structDavid Mitchell2014-02-281-0/+1
| | | | | | | | | | | | | Add an extra U32 general flags field to the xpvhv_aux struct (which is used on HVs such as stashes, that need extra fields). On 64-bit systems, this doesn't consume any extra space since there's already an odd number of I32/U32 fields. On 32-bit systems it will consume an extra 4 bytes. But of course only on those hashes that have the aux struct. As well as providing extra flags in the AUX case, it will also allow us to free up at least one general flag bit for HVs - see next commit.
* perlapi: Consistent spaces after dotsFather Chrysostomos2013-12-291-9/+10
| | | | plus some typo fixes. I probably changed some things in perlintern, too.
* Make mro code pass precomputed hash valuesFather Chrysostomos2013-11-041-0/+10
| | | | | | | | where possible This involved adding hv_fetchhek and hv_storehek macros and changing S_mro_clean_isarev to accept a hash parameter and expect HVhek_UTF8 instead of SVf_UTF8.
* hv.h: missing macro parenthesesFather Chrysostomos2013-11-041-1/+1
| | | | Let’s defuse this time bomb before it causes problems.
* When deleting via hek, pass the computed hash valueFather Chrysostomos2013-10-281-0/+6
| | | | | | | In those cases where the hash key comes from a hek, we already have a computed hash value, so pass that to hv_common. The easiest way to accomplish this is to add a new macro.
* [perl #79074] make sure HeSVKEY_force() preserves UTF8ness (pvn)Tony Cook2013-09-161-1/+3
| | | | | | | | | | HeSVKEY_force() is only used in two places in core. In the first case, the key is always stored as a SV (when handling tie magic, since NEXTKEY can only return a SV) The second case is in B::HE, but I don't see a way to create a B::HE object from a hash.
View Lorry Controller Status