Received: from hera.aquilenet.fr (hera.aquilenet.fr [185.233.100.1])
	by nld3-dev1.alpinelinux.org (Postfix) with ESMTPS id 249DF780780
	for <~alpine/users@lists.alpinelinux.org>; Tue,  2 Nov 2021 19:10:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
	by hera.aquilenet.fr (Postfix) with ESMTP id 0877DB5;
	Tue,  2 Nov 2021 20:10:44 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at aquilenet.fr
Received: from hera.aquilenet.fr ([127.0.0.1])
	by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id SWkdPNE5Kbbf; Tue,  2 Nov 2021 20:10:43 +0100 (CET)
Received: from webmail.aquilenet.fr (gaia.aquilenet.fr [IPv6:2a0c:e300::2])
	by hera.aquilenet.fr (Postfix) with ESMTPSA id DD39133A;
	Tue,  2 Nov 2021 20:10:42 +0100 (CET)
MIME-Version: 1.0
Date: Tue, 02 Nov 2021 20:10:42 +0100
From: =?UTF-8?Q?=C3=89loi_Rivard?= <eloi.rivard@aquilenet.fr>
To: Ariadne Conill <ariadne@dereferenced.org>
Cc: ~alpine/users@lists.alpinelinux.org
Subject: Re: Alpine Linux general performances
In-Reply-To: <4dcedd5d-e2ce-e8e-e231-874997bbe9f6@dereferenced.org>
References: <6df8863e77b970b466dbfc9a3a5c2bcec3199f48.camel@aquilenet.fr>
 <4dcedd5d-e2ce-e8e-e231-874997bbe9f6@dereferenced.org>
Message-ID: <ef1b404ddc3298adc2981a1453f7ff2e@aquilenet.fr>
X-Sender: eloi.rivard@aquilenet.fr
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-Spamd-Bar: /
Authentication-Results: hera.aquilenet.fr;
	none
X-Rspamd-Server: hera
X-Rspamd-Queue-Id: 0877DB5
X-Spamd-Result: default: False [0.61 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 RCPT_COUNT_TWO(0.00)[2];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 R_MIXED_CHARSET(0.71)[subject];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[]

Thank you for your valuable answer. I wasn't aware about that 
security-performance trade-off.

> One workaround might be to use jemalloc instead, which is available as
> a package.  I am investigating a way to make it possible to always use
> jemalloc instead of the hardened malloc for performance-critical
> workloads, but that will require some discussion with the musl author
> which I haven't gotten to yet.

Interesting. Would that take the form of a musl-jemalloc package for a 
system-wide usage?

Do you have thought on mimalloc and the Emerson Gomes benchmark 
blogpost?