Re: Status of optimiza tions - can have n ative buffers

[Bart Schaefer <schaefer@brasslantern.com>]

On Mar 4,  5:49am, Sebastian Gniazdowski wrote:
}
} Callgrind reveals the cause:
} 
} 59,930,247,427  arrlen_le [/usr/local/bin/zsh-5.3.1-dev-0_O2]

Yeah, I think we've already determined that we're not getting away from
that without a significant rewrite to stop managing arrays as simple
char ** pointers.

Although the following might help in some cases -- (v->start < 0) can't
be true very often or arrlen() would have shown up nearly as much as
arrlen_le(), but maybe this shaves a few unnecessary recounts?

Anyway changing from arrlen_le() to arrlen_gt() removes a couple of
tail calls, so this might get faster, and will also reveal how many
of those arrlen_le() are coming through here.

diff --git a/Src/params.c b/Src/params.c
index 8942fef..6164ba6 100644
--- a/Src/params.c
+++ b/Src/params.c
@@ -2101,10 +2101,14 @@ getstrvalue(Value v)
 	if (v->isarr)
 	    s = sepjoin(ss, NULL, 1);
 	else {
-	    if (v->start < 0)
-		v->start += arrlen(ss);
-	    s = (arrlen_le(ss, v->start) || v->start < 0) ?
-		(char *) hcalloc(1) : ss[v->start];
+	    if (v->start < 0) {
+		if ((v->start += arrlen(ss)) < 0)
+		    s = (char *) hcalloc(1);
+		else
+		    s = ss[v->start];
+	    } else
+		s = arrlen_gt(ss, v->start) ?
+		     ss[v->start] : (char *) hcalloc(1);
 	}
 	return s;
     case PM_INTEGER: