From debbugs-submit-bounces@debbugs.gnu.org Wed May 18 10:01:38 2022 Received: (at submit) by debbugs.gnu.org; 18 May 2022 14:01:38 +0000 Received: from localhost ([127.0.0.1]:33049 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nrKF8-00034J-3H for submit@debbugs.gnu.org; Wed, 18 May 2022 10:01:38 -0400 Received: from lists.gnu.org ([209.51.188.17]:37554) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nrKF4-00031p-V0 for submit@debbugs.gnu.org; Wed, 18 May 2022 10:01:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44810) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nrKF3-000256-KX for bug-guix@gnu.org; Wed, 18 May 2022 10:01:34 -0400 Received: from sender4-of-o51.zoho.com ([136.143.188.51]:21122) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nrKEt-000846-8Y; Wed, 18 May 2022 10:01:33 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1652882469; cv=none; d=zohomail.com; s=zohoarc; b=Qn5nYNNPyQMIrQm3N3WF8swQ6g+x4RwXS82BcN4pQfJHSxtGfcXiLQxUwwg7Aqf7b/VipTu3ufSr2WR/S94Re0sqPqlkxYB8YjiZwDP18damhEYKcCm8SOPjFoES/ASeXsNClETYua2j71jjn0XTDCnkZaBYU9dvIDArmi3VXYQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1652882469; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:MIME-Version:Message-ID:Subject:To; bh=gV5Ob8t7ZvuHDXn8fP33+Py781zwI88RqthA7T62hC4=; b=j/IDLhoiKUwhRvkifMp9QblCjSPkZKw3qtmbYD3u8d9LQVwiZcAWHUUWF96pTDrL1/KPMOkPw14S8hQfwHeov0cgyokV2hTU1+yzHsiFqhobW2W0qkYQwFt3ztrnEpHehbx8N+6Z2yuOGfaZVYH6FXAkp8FB/8jLg4LePWdazDk= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=elephly.net; spf=pass smtp.mailfrom=rekado@elephly.net; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1652882469; s=zoho; d=elephly.net; i=rekado@elephly.net; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=gV5Ob8t7ZvuHDXn8fP33+Py781zwI88RqthA7T62hC4=; b=doCotpDYZsDm/q6bDDvufjJrbjDh+VQwUy3c8+kOEo+Sjmf9zgWBWVVazOM51etj KLmtLrNBXKwgebif1JnQMhj2dHdbBTgtxGzNwJxfMQknvXUKM/5tgqOGiV625EDQtJw IRQ9hrLCWnO0KwJJyRODvvT7rmOPGzYM2BBmcSYw= Received: from localhost (118-108-142-46.pool.kielnet.net [46.142.108.118]) by mx.zohomail.com with SMTPS id 1652882468127716.8637033216065; Wed, 18 May 2022 07:01:08 -0700 (PDT) User-agent: mu4e 1.6.10; emacs 28.0.50 From: Ricardo Wurmus To: bug-guix@gnu.org Subject: excessively large manifests due to propagation Date: Wed, 18 May 2022 15:53:06 +0200 X-URL: https://elephly.net X-PGP-Key: https://elephly.net/rekado.pubkey X-PGP-Fingerprint: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC Message-ID: <87sfp7kkim.fsf@elephly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External Received-SPF: pass client-ip=136.143.188.51; envelope-from=rekado@elephly.net; helo=sender4-of-o51.zoho.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Packages of some languages rely heavily on propagation. R is one example. Since the generated =E2=80=9Cmanifest=E2=80=9D file of a Guix pro= file records entries for all propagated packages, this can get really big really quickly. A profile consisting only of four R packages (r-seurat, r-cistopic, r-monocle3, and r-cicero-monocle3) results in a =E2=80=9Cmanifest=E2=80=9D = file that weighs 7.1MB. At the MDC I repeatedly encountered manifest files that are exceeding 24MB. Simply reading that big a file with (call-with-input-file "huge-manifest" read) takes several seconds. On the MDC cluster I observed a delay of about 27 seconds. Disabling read positions with (read-disable 'positions) significantly speeds this up (18s vs 27s), but it=E2=80=99s still very slow. We may be able to speed things up by supporting definitions or references in manifest files, so that we don=E2=80=99t need to repeat a sub= -tree when generating the file. --=20 Ricardo