Re: [BUG] zformat -f has no multibyte support

["Daniel Shahaf" <d.s@xxxxxxxxxxxxxxxxxx>]

Daniel Shahaf wrote on Thu, 26 Dec 2019 05:04 +00:00:
> dana wrote on Thu, 26 Dec 2019 04:35 +00:00:
> > On 24 Dec 2019, at 14:23, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> > > Actually, I don't suppose we could just call into the printf code directly, can
> > > we?  It _works_ (see attachment), but it's not elegant.
> > 
> > A very quick before/after test shows that it reduces performance quite a bit,
> > especially as the number of format specs increases. Admittedly, it's only a
> > few µs per spec in absolute numbers (at least on my Mac, with the handful of
> > operations i tested),
> 
> What is the _factor_ of slowdown?  (Multiplicative, as opposed to additive)
> I.e., does the patch make things slower by 1%, or 10%, or 100%, or 1000%?

According to dana and I's results, the factor is between x4 and x29:

[[[
% for 1 in */Src/zsh; do printf "%-16s%s\n" $1:h:h $($1 -fc 'time ( zformat -f x ${(r.1000000..%a.):-} a:o )'); done
( zformat -f x ${(r.1000000..%a.):-} a:o; )  0.10s user 0.27s system 99% cpu 0.369 total
master          
( zformat -f x ${(r.1000000..%a.):-} a:o; )  1.04s user 0.33s system 99% cpu 1.372 total
patch           
]]]

[[[
# Without patch
[DEV] zsh % repeat 5 utime zformat -f x ${(r.10000..%a.):-} a:o
[429 µs]
[507 µs]
[499 µs]
[468 µs]
[609 µs]

# With patch
[DEV] zsh % repeat 5 utime zformat -f x ${(r.10000..%a.):-} a:o
[16577 µs]
[14063 µs]
[13941 µs]
[13972 µs]
[13569 µs]
]]]

I don't know how to explain the difference (we've both had other things to look into).