I've juts pushed the following merge commit: commit e958ef3d8fccb2d78757ebb06ce8b1030ef4f1d0 Merge: 72b09e4 60779a3 Author: David Mitchell <davem@iabyn.com> AuthorDate: Thu Feb 27 16:32:34 2014 +0000 Commit: David Mitchell <davem@iabyn.com> CommitDate: Thu Feb 27 16:32:34 2014 +0000 [MERGE] optmise pp_entersub code Do various bits of minor fiddling with the code of Perl_pp_entersub to make the binary smaller and hopefully faster. All the usual stuff: sprinkling LIKELY(), altering scope of vars etc. All of this should make no functional difference, expect conceivably the "SvPADTMP() not on IS_PADGV()" change (which also affects code outside pp_entersub()). This series of commits reduces the size of the pp_entersub object on gcc x86_64 by about 11%, and shows no measurable change in performance (i.e. noise dominates). It's fairly uncontroversial, except for perhaps the following one commit, which I thought I'd flag, in case anyone can see anything wrong with it: commit 60779a30f61297ad86e175f686b7bc697c7b8e51 Author: David Mitchell <davem@iabyn.com> AuthorDate: Thu Feb 27 15:30:26 2014 +0000 Commit: David Mitchell <davem@iabyn.com> CommitDate: Thu Feb 27 16:16:18 2014 +0000 don't set SvPADTMP() on PADGV's Under threaded builds, GVs for OPs are stored in the pad rather than being directly attached to the op. For some reason, all such GV's were getting the SvPADTMP flag set. There seems to be be no good reason for this, and after skipping setting the flag, all tests still pass. The advantage of not setting this flag is that there are quite a few hot places in the code that do if (SvPADTMP(sv) && !IS_PADGV(sv)) { ... I've replaced them all with if (SvPADTMP(sv)) { assert(!IS_PADGV(sv)); ... Since the IS_PADGV() macro expands to something quite heavyweight, this is quite a saving: for example this commit reduces the size of pp_entersub by 111 bytes. -- The Enterprise is captured by a vastly superior alien intelligence which does not put them on trial. -- Things That Never Happen in "Star Trek" #10