optimize SV creation funcs in sv.c

In Perl_newSV, the sv_upgrade is redundant, except to protect against a
segv in blindly SV body derefing SvGROW (but not in sv_grow). sv_grow has
always upgraded a non-PV SV to PV. So don't it here. Since a new SV will
never have be a COW, have a SvLEN or a body, all of which SvGROW uses,
just call sv_grow. Less branching, and smaller code that way.

In Perl_newSV_type, give a hint to compiler that if a platform's
symbol visibility allows inlining, and newSV_type's arg is the base type
(currently SVt_NULL, maybe SVt_IV in future (see ML)), to possibly inline
new_SV into the caller and remove the sv_upgrade call. Also don't call
sv_upgrade if it isn't needed (SVt_NULL) in the public symbol version.

The redundant sv_upgrade then sv_grow goes to commit 79072805bf
"perl 5.0 alpha 2". VC 2003 -01 32 bit threaded machine code size in bytes
of 2 functions
Perl_newSV_type before 0x2f after 0x29
Perl_newSV  before 0x48 after 0x28

1 files changed, 4 insertions, 3 deletions

diff --git a/sv.c b/sv.c
index c3594b20d3..91ca012c11 100644
--- a/sv.c
+++ b/sv.c
@@ -5573,8 +5573,7 @@ Perl_newSV(pTHX_ const STRLEN len)
 
     new_SV(sv);
     if (len) {
-	sv_upgrade(sv, SVt_PV);
-	SvGROW(sv, len + 1);
+	sv_grow(sv, len + 1);
     }
     return sv;
 }
@@ -9345,7 +9344,9 @@ Perl_newSV_type(pTHX_ const svtype type)
     SV *sv;
 
     new_SV(sv);
-    sv_upgrade(sv, type);
+    ASSUME(SvTYPE(sv) == SVt_FIRST);
+    if(type != SVt_FIRST)
+	sv_upgrade(sv, type);
     return sv;
 }