From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 04819E00A for ; Tue, 6 Dec 2022 16:01:30 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 700C52FC9F for ; Tue, 6 Dec 2022 16:01:29 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Tue, 6 Dec 2022 16:01:27 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 25F1343CCD for ; Tue, 6 Dec 2022 16:01:27 +0100 (CET) Date: Tue, 6 Dec 2022 16:01:26 +0100 From: Wolfgang Bumiller To: Lukas Wagner Cc: pbs-devel@lists.proxmox.com Message-ID: <20221206150126.5gjsx5hn6blzxwo7@casey.proxmox.com> References: <20221205145514.645111-1-l.wagner@proxmox.com> <20221205145514.645111-3-l.wagner@proxmox.com> <20221206113941.ozvlonsqil34impj@casey.proxmox.com> <41086f37-8fea-8cda-ae90-1c152ef4b047@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41086f37-8fea-8cda-ae90-1c152ef4b047@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.225 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [PATCH v2 proxmox-backup 2/3] debug cli: add 'compare-content' flag to `diff archive` command X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2022 15:01:30 -0000 On Tue, Dec 06, 2022 at 03:44:07PM +0100, Lukas Wagner wrote: > Hi, > > On 12/6/22 12:39, Wolfgang Bumiller wrote: > > > +{ > > > + let mut buf_a = vec![0u8; BUFFERSIZE]; > > > + let mut buf_b = vec![0u8; BUFFERSIZE]; > > > > Maybe use a Box instead of a Vec, we don't ever resize this atm. > > > > Do you mean like this? > let mut buf_a = Box::new([0u8; BUFFERSIZE]); > > AFAIU this would construct the array on the stack first before it is moved into the Box, > leading to some unnecessary memcpys. Or am I missing something here? With these sizes - and this is only on the CLI AFAICT - this is not an issue, and in --release builds this will be optimized out. I prefer not to do things weirdly because "the compiler does stupid things" if it can be avoided. (Some kind of "placement-new"-like construct is *really* missing in rust...) And none of `Box::new_zeroed*`, `Box::new_uninit*` are stable yet, and even if they were, there's no ergonomic POD version that doesn't imply a `MaybeUninit`. Perhaps we should start a proxmox_bytes crate where we move proxmox_io::vec to, and add a box module for box::zeroed() and box::uninit()...