| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
$ perl5.18.1 -e '$Foo::{"Bar::"} = 0; $Bar::Bar::; *Bar:: = *Foo::'
Segmentation fault: 11
That $Foo::{"Bar::"} = 0; assignment is documented as having unde-
fined behaviour, but it shouldn’t crash.
|
|
|
|
|
|
|
|
| |
This is part of ticket #119433.
Commit ce0d49f changed AVs to use NULL for nonexistent elements. The
mro lookup code was not accounting for that, causing Class::Contract’s
tests to crash (and perhaps other modules, too).
|
|
|
|
|
|
|
| |
Iterated hashes shouldn’t have to allocate space for something
specific to stashes, so move the SUPER method cache from the
HvAUX struct (which all iterated hashes have) into the mro
meta struct (which only stashes have).
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 95f9781bc2fad025553db0160ef9c2c5363312a1.
Now that the crash has been fixed by the preceding commit, we can
reinstate 7cc6787e9db.
|
|
|
|
|
|
|
|
| |
This reverts commit 7cc6787e9dbebdd83799d997361188ab6dfe8ead.
That commit is causing crashes on Windows for some as yet unknown rea-
son. (See ticket #115830.) I don’t have time to fix it before the
release of 5.17.6.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I changed it to cache the DESTROY method in SvSTASH(stash), instead
of amagic tables, for the sake of speed. But I made no distinction
between ‘no cache’ and ‘no DESTROY method’. So classes with no
DESTROY method became as slow as perl 5.6.
To solve that, I’m using an adjusted pointer (following the example
of warnings.h) to mean ‘intentionally blank’.
I also fixed two instances of the DESTROY cache not being updated,
introduced by that commit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DESTROY has been cached in overload tables since
perl-5.6.0-2080-g32251b2, making it 4 times faster than before (over-
load tables are faster than method lookup).
But it slows down symbol lookup on stashes with overload tables,
because overload tables use magic, and SvRMAGICAL results in calls to
mg_find on every hash lookup.
By reusing SvSTASH(stash) to cache the DESTROY method (if the stash
is unblessed, of course, as most stashes are), we can avoid making
all destroyable stashes magical and also speed up DESTROY lookup
slightly more.
The results:
• 10% increase in stash lookup speed after destructors. That was just
testing $Foo::{x}. Other stash lookups will have other overheads
that make the difference less impressive.
• 5% increase in DESTROY lookup speed. I was using an empty DESTROY
method to test this, so, again, real DESTROY methods will have more
overhead and less speedup.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As discussed in ticket #114820, instead of using READONLY+FAKE to mark
a copy-on-write string, we should make it a separate flag.
There are many modules in CPAN (and 1 in core, Compress::Raw::Zlib)
that assume that SvREADONLY means read-only. Only one CPAN module,
POSIX::pselect will definitely be broken by this. Others may need to
be tweaked. But I believe this is for the better.
It causes all tests except ext/Devel-Peek/t/Peek.t (which needs a tiny
tweak still) to pass under PERL_OLD_COPY_ON_WRITE, which is a prereq-
uisite for any new COW scheme that creates COWs under the same cir-
cumstances.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes most register declarations in C code (and accompanying
documentation) in the Perl core. Retained are those in the ext
directory, Configure, and those that are associated with assembly
language.
See:
http://stackoverflow.com/questions/314994/whats-a-good-example-of-register-variable-usage-in-c
which says, in part:
There is no good example of register usage when using modern compilers
(read: last 10+ years) because it almost never does any good and can do
some bad. When you use register, you are telling the compiler "I know
how to optimize my code better than you do" which is almost never the
case. One of three things can happen when you use register:
The compiler ignores it, this is most likely. In this case the only
harm is that you cannot take the address of the variable in the
code.
The compiler honors your request and as a result the code runs slower.
The compiler honors your request and the code runs faster, this is the least likely scenario.
Even if one compiler produces better code when you use register, there
is no reason to believe another will do the same. If you have some
critical code that the compiler is not optimizing well enough your best
bet is probably to use assembler for that part anyway but of course do
the appropriate profiling to verify the generated code is really a
problem first.
|
|
|
|
|
| |
This updates the editor hints in our files for Emacs and vim to request
that tabs be inserted as spaces.
|
|
|
|
|
|
| |
If a non-overloaded class begins inheriting overloading due to @ISA
changes, we need to set the overloaded (AMAGIC) flag on the stash to
indicate that. Updating caches shouldn’t require a dummy blessing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of setting a class’s overloaded (HvAMAGIC) flag when bless
happens, we should do it in ‘use overload’. Otherwise, if a non-over-
loaded class gains overloading via ‘use overload’, existing objects
won’t get overloading until another object is blessed into the
same class.
Inherited overloading that is turned on due to @ISA changes still
won’t work yet. That will come in a later commit.
Doing this via %OVERLOAD magic would require referencing
the stash from magic. Since overload.pm already does
‘*{$package . "::()"} = \&nil’, triggering mro_method_changed_in,
the simplest approach is to turn on the stash’s AMAGIC flag in
mro_method_changed_in. Since, if there is no overloading, the flag
will be turned off on the next attempted overload call (in Gv_AM in
sv.h), there should be noticeable slowdown.
I had to turn off HvAMAGIC in hv_undef, to prevent ‘Can't use anony-
nous symbol table for method lookup’ from occurring when stringifying
an object whose package has been undefined.
|
|
|
|
|
|
|
| |
Sync copyright dates with actual changes according to git history.
[Plus run regen_perly.h to update the SHA-256 checksums, and
regen/regcharclass.pl to update regcharclass.h]
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Based on the warning from:
http://www.nntp.perl.org/group/perl.daily-build.reports/2011/11/msg108741.html
which I haven't been able to produce in any other compiler.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Perl has assumed up till now that the first element of an isa linear-
isation is the name of the class itself. That is true for dfs and c3,
but not requiring that makes it easier for plugin authors.
Since various parts of the mro code make that assumption, this commit
copies the AV returned by mro_alg.resolve to a new one beginning with
the class’s own name, if the original AV did not include it.
|
|
|
|
| |
I had to look in embed.fnc to find this out when I wanted to use it.
|
| |
|
|
|
|
| |
This avoids creating a lot of temporary SVs.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous commit introduced some code that concatenates a pv on to
an sv and then does SvUTF8_on on the sv if the pv was utf8.
That can’t work if the sv was in Latin-1 (or single-byte) encoding
and contained extra-ASCII characters. Nor can it work if bytes are
appended to a utf8 sv. Both produce mangled utf8.
There is apparently no function apart from sv_catsv that handle
this. So I’ve modified sv_catpvn_flags to handle this if passed the
SV_CATUTF8 (concatenating a utf8 pv) or SV_CATBYTES (cancatenating a
byte pv) flag.
This avoids the overhead of creating a new sv (in fact, sv_catsv
even copies its rhs in some cases, so that would mean creating two
new svs). It might even be worthwhile to redefine sv_catsv in terms
of this....
|
|
|
|
|
|
|
|
|
|
|
| |
This patch also duplicates existing mro tests with copies that use
Unicode in identifiers, to test the mro code.
Since those tests trigger it, it also fixes a bug in the parsing
of *{...}: If the first character inside the braces is a non-ASCII
Unicode identifier character, the inside is now implicitly quoted
if it is just an identifier (just as it is with ASCII identifiers),
instead of being parsed as a bareword that would violate strict subs.
|
| |
|
|
|
|
|
| |
This has been out of date since the MRO plugin API was added
(5.10.1, I think).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This:
commit 8aacddc1ea3837f8f1a911d90c644451fc7cfc86
Author: Nick Ing-Simmons <nik@tiuk.ti.com>
Date: Tue Dec 18 15:55:22 2001 +0000
Tidied version of Jeffrey Friedl's <jfriedl@yahoo.com> restricted hashes
- added delete of READONLY value inhibit & test for same
- re-tabbed
p4raw-id: //depot/perlio@13760
essentially deprecated HvKEYS() in favor of HvUSEDKEYS(); this is
explained in line 144 (now 313) of file `hv.h':
/*
* HvKEYS gets the number of keys that actually exist(), and is provided
* for backwards compatibility with old XS code. The core uses HvUSEDKEYS
* (keys, excluding placeholdes) and HvTOTALKEYS (including placeholders)
*/
This commit simply puts that into practice, and is equivalent to running
the following (at least with a35ef416833511da752c4b5b836b7a8915712aab
checked out):
git grep -l HvKEYS | sed /hv.h/d | xargs sed -i s/HvKEYS/HvUSEDKEYS/
Notice that HvKEYS is currently just an alias for HvUSEDKEYS:
$ git show a35ef416833511da752c4b5b836b7a8915712aab:hv.h | sed -n 318p
#define HvKEYS(hv) HvUSEDKEYS(hv)
According to `make tests':
All tests successful.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 088225f was not sufficient to fix the regression. It still
exists for packages whose names end with a single colon.
I discovered this when trying to determine why RDF::Trine was crashing
with 5.14-to-be.
In trying to write tests for it, I ended up triggering the same crash
that RDF::Trine is having, but in a different way.
In the end, it was easier to fix about three or four bugs (depending
on how you count them), rather than try to fix only the regression
that #88132 deals with (isa caches not updating when packages ending
with colons are aliased), as they are all intertwined.
The changes are as follows:
Concerning the if (!(flags & ~GV_NOADD_MASK)...) statement in
gv_stashpvn: Normally, gv_fetchpvn_flags (which it calls and whose
retval is assigned to tmpgv) returns NULL if it has not been told
to add anything and if the gv requested looks like a stash gv (ends
with ::). If the number of colons is odd (foo:::), that code path is
bypassed, so gv_stashpvn returns a GV without a hash. So gv_stashpvn
tries to used that NULL hash and crashes. It should instead return
NULL, to be consistent with the two-colon case.
Blindly assigning a name to a stash does not work if the stash has
multiple effective names. A call to mro_package_moved is required as
well. So what gv_stashpvn was doing was insufficient.
The parts of the mro code that check for globs or stash elems that
contain stashes by looking for :: at the end of the name now take into
account that the name might consist of a single : instead.
|
|
|
|
|
|
|
|
|
| |
# New Ticket Created by (Peter J. Acklam)
# Please include the string: [perl #81904]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=81904 >
Signed-off-by: Abigail <abigail@abigail.be>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This code is never reached if oldstash is a hash without an HvENAME.
So instead of checking oldstash in the ?:, then hvename in the if(),
we can do one check.
If oldstash is no longer in the symbol table, then this code is never
reached, because of the if(!fetched_isarev) guard.
|
| |
|
|
|
|
| |
And similarly for newSVpvn() for a known length.
|
|
|
|
|
| |
This avoids a lot of casting. Nothing outside the perl core code is accessing
that member directly.
|
|
|
|
|
| |
There is a similar check about fifty lines back.
And it is silly to check HvARRAY on a named hash.
|
|
|
|
|
|
|
|
|
|
|
|
| |
See the test case in the commit. It passes in 5.8.x and blead (as of
this commit), but not 5.10-5.13.7.
In every case the name to be passed to mro_gather_and_rename is cre-
ated using an SV, so we might as well pass that instead of extracting
the char array and length from it.
That allows us to pass an AV instead, if there are multiple names to
take into account.
|
|
|
|
|
| |
We will need this for making the API UTF8-aware in 5.16
or whenever.
|
|
|
|
| |
Nothing is using this any more, as of the previous commit.
|
|
|
|
|
| |
This was supposed to have been removed by 80ebaca, when negative val-
ues for the newname_len argument stopped being used.
|
|
|
|
|
|
|
| |
This stops S_hv_delete_common from skipping the call to
mro_package_moved if the HvNAME of the stash containing the deleted
glob is no longer valid, but the stash is still attached to some other
part of the symbol table.
|
|
|
|
|
|
|
|
|
|
| |
We can avoid the double iteration by doing the first iteration’s job
(to clear the linearisations) inside gather_and_rename as the items
are added to the stash. The important thing is that they all be
cleared before *any* calls to mro_isa_changed_in, which will still
be the case.
Maybe ‘gather_and_rename’ is not such a good name any more....
|