From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 96f61f18 for ; Thu, 26 Dec 2019 05:05:27 +0000 (UTC) Received: (qmail 27325 invoked by alias); 26 Dec 2019 05:05:22 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 45144 Received: (qmail 6255 invoked by uid 1010); 26 Dec 2019 05:05:22 -0000 X-Qmail-Scanner-Diagnostics: from out1-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.1/25670. spamassassin: 3.4.2. Clear:RC:0(66.111.4.25):SA:0(-2.6/5.0):. Processed in 4.279311 secs); 26 Dec 2019 05:05:22 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvddvhedgjeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdffrghnihgvlhcuufhhrghhrghffdcuoegurdhssegu rghnihgvlhdrshhhrghhrghfrdhnrghmvgeqnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gurdhssegurghnihgvlhdrshhhrghhrghfrdhnrghmvgenucevlhhushhtvghrufhiiigv pedt X-ME-Proxy: X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-694-gd5bab98-fmstable-20191218v1 Mime-Version: 1.0 Message-Id: <027d3c24-e3d1-4cfd-8c3e-5221998a327f@www.fastmail.com> In-Reply-To: <8CB7B64F-BFB9-49C9-ACDD-AA60D58873E2@dana.is> References: <20191223222436.rtsmhs4xuug2jfum@localhost> <20191224202327.or5yuftjieyq5z2o@tarpaulin.shahaf.local2> <8CB7B64F-BFB9-49C9-ACDD-AA60D58873E2@dana.is> Date: Thu, 26 Dec 2019 05:04:20 +0000 From: "Daniel Shahaf" To: zsh-workers@zsh.org Subject: Re: [BUG] zformat -f has no multibyte support Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable dana wrote on Thu, 26 Dec 2019 04:35 +00:00: > On 24 Dec 2019, at 14:23, Daniel Shahaf wrote= : > > Actually, I don't suppose we could just call into the printf code di= rectly, can > > we? It _works_ (see attachment), but it's not elegant. >=20 > 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 o= nly a > few =C2=B5s 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 additi= ve) I.e., does the patch make things slower by 1%, or 10%, or 100%, or 1000%= ? > and i don't know how that would compare with a > 'lower-level' approach. I assume that multi-byte support will incur *s= ome* > penalty no matter how it's done, so maybe it's reasonable, idk. I don't have an intuition for what the penalty should be, but to get a sense of the orders of magnitude involved we could the behaviour of the 'printf' builtin when built with and without multibyte support. Thanks, Daniel