From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: native compilation units Date: Tue, 14 Jun 2022 00:19:06 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000005be4d105e160b5a7" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11963"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Andrea Corallo , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 14 06:24:00 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o0y5v-0002ps-QN for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Jun 2022 06:23:59 +0200 Original-Received: from localhost ([::1]:42046 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o0y5u-0001sY-AS for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Jun 2022 00:23:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48886) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o0y1U-00035d-2H for emacs-devel@gnu.org; Tue, 14 Jun 2022 00:19:24 -0400 Original-Received: from mail-ua1-x929.google.com ([2607:f8b0:4864:20::929]:38406) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o0y1R-0001bA-Mv for emacs-devel@gnu.org; Tue, 14 Jun 2022 00:19:23 -0400 Original-Received: by mail-ua1-x929.google.com with SMTP id l12so2878308uan.5 for ; Mon, 13 Jun 2022 21:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PYb0JGtTboCnoQr+9RxU1e88O2Dd/sirN5A8/Xs88VM=; b=XNrQrQV6j1n0Kq6AW7BSmdbEwyw1wa1KeTiocMEMISr7mvh6+F265Df9AybHJFiI11 mprhkVaPla+Osh6hE5w35ZzBUGewQgNS1yMYRzjoVHAARh5QUWAbgdNn5nde3W8XxpWn TqTdonbhSRDsBr8XtvLG9gNd/e0sETbHnXwiT8G7l7Y5skp4G/bc9qqy8RX/YQf7yZ5W byrxjr2B4Sz/caquN6x11NJT6uwniptFKr+pvg8vI1GyZFr0SbvGeUXE/cFYlZPdblJJ WZdjCFPKtCS01X9hMHc23BVVz/L7BvIFdCihsjvQz34cWTE3tsulITtUd4wXFY8wQex7 69qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PYb0JGtTboCnoQr+9RxU1e88O2Dd/sirN5A8/Xs88VM=; b=tF9PRQKHTk7hMYeBdtnMUNNAUQ+6b1LjWhLc2zjorAovm1gb4FT3dpyvU0ffPRZBYF EbUkA85UcZkGg4oYqLRrvmzwjTKywpkWCYr8RuAHLHOg8Eew1cHQP+Tl9g97efdwFup0 5zn5MvzrgXe2WDFy+pM/XIRXQGfHRK75y71CFm1NsfK/RXd41YaGyF+3zLpw+P9U/73a UXb7m7eepKLY5iDP8aXV09p9dG6BNwKPDHX5JPNGfZEEoP+nXOL9JAvSbQq51ETEWZEx zHB32fhjtOQJF1QOP6LWZJigHFuo5wKETt7Sqvjy8Dk8Ol2HIXy74NFVw5Kpl8dSoKSd 4hmw== X-Gm-Message-State: AJIora/dRFRdOCuYJPezQ9vf0y+gLhv2kE+pNI9RS5NHgWeLQwAFGrQK AGRpRQYacGMrom2HHmKExoNRxu5J4wqUkFA2zUM= X-Google-Smtp-Source: AGRyM1vxl96kCR3g/D8nvtKixfs79QPRH7pyIRTVtZKFKtyDKliVTydrFlMdryrxrKtAGDM98NXayf/43rrXMm4jW6g= X-Received: by 2002:ab0:6dcf:0:b0:379:ac4:813b with SMTP id r15-20020ab06dcf000000b003790ac4813bmr1318263uaf.88.1655180359360; Mon, 13 Jun 2022 21:19:19 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::929; envelope-from=owinebar@gmail.com; helo=mail-ua1-x929.google.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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:291163 Archived-At: --0000000000005be4d105e160b5a7 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 5, 2022 at 10:20 AM Stefan Monnier wrote: > > >> Also, what kind of startup time are you talking about? > >> E.g., are you using `package-quickstart`? > > That was the first alternative I tried. With 1250 packages, it did not > > work. > > Please `M-x report-emacs-bug` (and put me in `X-Debbugs-Cc`). > > I was able to reproduce this at home on cygwin with 940 packages. I had tried to install a few more than that (maybe 945 or something), I just removed the corresponding sections of the last few until it did compile. Then I verified that it didn't matter whether I removed the first or the last package autoloads, I would get the overflow regardless. After spending the weekend going over byte code examples, I looked at the output, and it's literally just hitting 64k instructions. Each package uses 17 instructions just putting itself on the loadpath, which accounts for ~15000 instructions. That means every package uses about 50 instructions on average, so (if that's representative), you wouldn't expect to be able to do much more than 300 or so additional packages just from putting those paths in an array and looping over them. Most of the forms are just calls to a handful of operators with constant arguments, so I would assume you could just create arrays for the most common instruction types, put the argument lists in a giant vector, and then just loop over those vectors performing the operator. Then there'd be a handful of oddball expressions to handle. Or, you could just create a vector with one thunk for each package and loop through it invoking each one. It wouldn't be as space efficient, but it would be trivially correct. I'll put this in a bug report. Lynn --0000000000005be4d105e160b5a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jun 5, 2022 at 10:20 AM Stefan Mo= nnier <monnier@iro.umontreal= .ca> wrote:

>> Also, what kind of startup time are you talking about?
>> E.g., are you using `package-quickstart`?
> That was the first alternative I tried.=C2=A0 With 1250 packages, it d= id not
> work.

Please `M-x report-emacs-bug` (and put me in `X-Debbugs-Cc`).


I was able to reproduce this at home on cygwin w= ith 940 packages. I had
tried to install a few more than that (ma= ybe 945 or something), I just
removed the corresponding sections = of the last few until it did compile.
Then I verified that it did= n't matter whether I removed the first or the last
package au= toloads, I would get the overflow regardless.
After spending the = weekend going over byte code examples, I=C2=A0 looked
at the outp= ut, and it's literally just hitting 64k instructions.=C2=A0 =C2=A0Each = package
uses 17 instructions just putting itself on the loadpath,= which accounts for ~15000
instructions.=C2=A0 That means every p= ackage uses about 50 instructions on average,
so (if that's r= epresentative), you wouldn't expect to be able to do much more than 300=
or so additional packages just from putting those paths in an ar= ray and looping over them.
Most of the forms are just calls to a = handful of operators with constant arguments,
so I would assume y= ou could just create arrays for the most common instruction types, put the<= /div>
argument lists in a giant vector, and then just loop over those v= ectors performing the operator.
Then there'd be a handful of = oddball expressions to handle.

Or, you could just = create a vector with one thunk for=C2=A0each package and loop through=C2=A0= it
invoking each one.=C2=A0 It wouldn't be as space efficien= t, but it would be trivially correct.

I'll put= this in a bug report.

Lynn


--0000000000005be4d105e160b5a7--