>On a somewhat related note, I noticed that the string structure no
>longer has extra padding bytes available, so adding new string types
>(substring) is not possible without increasing it's size
As it turs out, by shrinking the size_shift field to 2 bits there are
6 bytes left for types instead of the previous 2. So now a lot of new
allocation types could be added, in theory.
I created the substring type on a branch, it does help with the naive
cut-prefix-of-string buffer code case, at least. :)
Making size_shift a bitfields add an compiler-generation &3 to each
access of it, more or less. This could cause a noticeable general
slowdown, I have not checked if this is the case.
With patch:
> string s = random_string(1024*1024);
> set format bench
> lambda(string s){while(strlen(s))s=s[1..];}(s);
Compilation: 549ns, Execution: 83.55ms
Without patch:
Compilation: 505ns, Execution: 35.16s
So, for 1Mb it's 400+ times faster. Of course, it's the ordo that is
faster, the actual string_slice substring generation code is somewhat
slower (for small values of 'somewhat').
