From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: arthur miller Newsgroups: gmane.emacs.devel Subject: RE: On elisp running native Date: Thu, 2 Jan 2020 07:55:27 +0000 Message-ID: References: <83tv5mp48l.fsf@gnu.org> <83sgl0lchm.fsf@gnu.org> <83imlwl9vm.fsf@gnu.org> , Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_VI1P194MB0429F3AF7407F4318D67FA5196200VI1P194MB0429EURP_" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="31123"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Eli Zaretskii , "emacs-devel@gnu.org" To: Andrea Corallo , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 02 08:58:33 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1imvNJ-0007xm-4D for ged-emacs-devel@m.gmane.org; Thu, 02 Jan 2020 08:58:33 +0100 Original-Received: from localhost ([::1]:38066 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1imvNH-0002yd-TF for ged-emacs-devel@m.gmane.org; Thu, 02 Jan 2020 02:58:31 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37572) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1imvKc-0007fZ-Jz for emacs-devel@gnu.org; Thu, 02 Jan 2020 02:55:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1imvKa-00082t-TC for emacs-devel@gnu.org; Thu, 02 Jan 2020 02:55:46 -0500 Original-Received: from mail-oln040092066105.outbound.protection.outlook.com ([40.92.66.105]:12677 helo=EUR01-VE1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1imvKM-0007pR-K4; Thu, 02 Jan 2020 02:55:31 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jr6Km0UZEsk8YogsOzrH6r7k9a5625vQenFXf7F7USJxaTvzICx2DMpmq0EHaaM7h6mHISIYJGZoLK68AUkX9q1tAbTuNDgVLOtr5W0PjgAACRIaIgai5bQIlvuUzOG1xm8lm4WzgcyAaOcjPJpP0D0AREc8SKT2XC45CbdNvl2EC1vuuLdl73dhTucC2i6ZRgH0Q5oBuOsA3SfcqLWzc5GamtVfVw0c7guv5qd1rQO9YIRUNzpAJJt+Dpp/CnN4Zf+PPVuhge7TRjbhNIwKwk6wJDKzHmfm0u13RUSd7QGJlJ4jkRCDTNzRaX2ADt2khELI2Tyrm26kv+FlKL3QFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0aLmOS+qLUrK1D/xQW6mDZcwQ2IDNBW905wCVM1uCu0=; b=CCBYWcItDNVk+r9w70FhiyLO5YYrra2MYPiS7J0WkX3lUxfUG+KGtItvWhRAvmlS6vGY/P0i5RTxCE6eTlC0tVuTyEBVKLGrS4NFJCJtHp3FDSTQB4LqwKx/0uq4Sj8K028KqVJSLDpyOLGw7BSTkEAa+ZhBKF6qYz1r3kw/qdEJ8sfSxQOg/Z26TtoWSxERcIQD0XvPIHKUK/Dza8yQnTYXlYBh8Wx+Xl57+TOiR/9SPi2vAQ4GSYjeKAT7gNH7DXYbdbN6BGqhhlc4LCPBKBahJ4htXVfDhwWOrHF3yQoVyb+JBDZw1zsbWhceVO8yqWghyVcxsM2OIETJNfy7ug== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0aLmOS+qLUrK1D/xQW6mDZcwQ2IDNBW905wCVM1uCu0=; b=s8Lp5/KMaDbDMm/FbQqS/5e0fdTSbFlFaXN/lFz3sGNWZ08YCy7U/bHyEMYZ381dMnLHIaoPMdHWPiwM4gfkFB06nuY0bN/s5sBh5pRBwJXyyBr4MV3tYY5JABrf3dF8G1U3WmzmqiHECPzhzgaPAbsjcLhUC85GMOZidfmHvpEirz6gHQDWGur6WD7zxFiBdcgS4v/NQEGt7erR3tv080hSAr7y4Y+L+J6kMQrcTKdlZG9TGYI7yAgXRxEsB8/MkI8pmOzg+atsJUptaniC1KDWLrED+Jfbc3RlBv/W14/BrjQJu7yXwOHcF/QVGQk94c196vuz0FXwnDpSoC5PJw== Original-Received: from VE1EUR01FT005.eop-EUR01.prod.protection.outlook.com (10.152.2.57) by VE1EUR01HT214.eop-EUR01.prod.protection.outlook.com (10.152.2.178) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11; Thu, 2 Jan 2020 07:55:28 +0000 Original-Received: from VI1P194MB0429.EURP194.PROD.OUTLOOK.COM (10.152.2.60) by VE1EUR01FT005.mail.protection.outlook.com (10.152.2.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11 via Frontend Transport; Thu, 2 Jan 2020 07:55:28 +0000 Original-Received: from VI1P194MB0429.EURP194.PROD.OUTLOOK.COM ([fe80::35f2:9ea2:efd6:1d46]) by VI1P194MB0429.EURP194.PROD.OUTLOOK.COM ([fe80::35f2:9ea2:efd6:1d46%5]) with mapi id 15.20.2602.012; Thu, 2 Jan 2020 07:55:28 +0000 Thread-Topic: On elisp running native Thread-Index: AQHVu+0613tDdbC3H0+0Q0VwAZ7Sn6fM3dgCgAAZTiCAAK6yh4AGa3vIgABbRiSAAAiNIoAABzTKgAFNucKAACrk2oAAOZ2DgADdj3g= In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: sv-SE x-incomingtopheadermarker: OriginalChecksum:62B9C86B578D2F8423DCD3B1CA163B68A3DD1F06DDEE56F53226FB2F008AD376; UpperCasedChecksum:3ADBF016E87393145E534A0B6C9426DCBB16630AE03A3279574DED7868790766; SizeAsReceived:7301; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [3RcblrOZTQYIEY3ecpulkhYdl1b4g7/D] x-ms-publictraffictype: Email x-incomingheadercount: 46 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 84078657-4d96-49da-4959-08d78f5921f1 x-ms-traffictypediagnostic: VE1EUR01HT214: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8DLgFMg67a6cL+/ZIwRMrAD8rA4XBXTGgBM19jRGl61o+qRWfZqE08rHP5+i3tjEnB1rfqI9BWXzomIcgwXtVOAs07uJEA8E+ramOiwku43hbOrM880pLevZ/Wrr3mC4A8D/bkEELDx+ZzOqjlo8dR+k+l6FvwdVEbqbgLahr8nl3uavFw7ZqMsQo3crhWjs x-ms-exchange-transport-forked: True X-OriginatorOrg: live.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 84078657-4d96-49da-4959-08d78f5921f1 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2020 07:55:27.9487 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR01HT214 X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 [fuzzy] X-Received-From: 40.92.66.105 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:243854 Archived-At: --_000_VI1P194MB0429F3AF7407F4318D67FA5196200VI1P194MB0429EURP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A question: Would it be possible to lump all compiled functions into one .so file per p= ackage? I have tested your branch after update2, haven't had time to test after the= last update. I didn't see any speedup on load time, either with -Q flag, o= r when I loaded my init files and packages. I have complied all elpa packag= es to eln, including my custom lisp and init file (whatever was compilable)= . I guess since there is one .eln per .el file, there is lots of disk access.= Same for byte code and pure lisp. Maybe the init time is dominated by file= access, rather then the processing those files. Could it maybe be possible to create one .so per package si that all functi= ons from corresponding eln files is that .so? It could drastically reduce n= umber of file access at load time. I don't know if it is possible. Skickat fr=E5n min Samsung Galaxy-smartphone. -------- Originalmeddelande -------- Fr=E5n: Andrea Corallo Datum: 2020-01-01 19:42 (GMT+01:00) Till: Stefan Monnier Kopia: Eli Zaretskii , emacs-devel@gnu.org =C4mne: Re: On elisp running native Stefan Monnier writes: > I think the focus should be on: > - making it work everywhere > - making it easy/convenient to use (e.g. even if you share your $HOME bet= ween > different architectures or even different OSes as well as different > versions of Emacs) I think the natural action would be to move the eln in the build directory (as these are in fact compiled). Unfortunately this would not work with the elpa packages... The other option would be to add a suffix to the the eln file but is not nice at all. Any idea? Consider that now the situation is pretty bad because eln are likely not to be compatible even from different builds on the same codebase with different configure parameters. > As far as I'm concerned, support for a nil value of lexical-binding is > a non-goal (it should still work, of course, e.g. by using the > bytecode): the dynbind version of Elisp is a legacy language and it's > better to update the code to lexbind than to try and make that legacy > code run faster. Good I agree, and even if not that hard would be something more to care about. -- akrl@sdf.org --_000_VI1P194MB0429F3AF7407F4318D67FA5196200VI1P194MB0429EURP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A question:

Would it be possible to lump all compiled functions into = one .so file per package?

I have tested your branch after update2, haven't had time= to test after the last update. I didn't see any speedup on load time, eith= er with -Q flag, or when I loaded my init files and packages. I have compli= ed all elpa packages to eln, including my custom lisp and init file (whatever was compilable).

I guess since there is one .eln per .el file, there is lo= ts of disk access. Same for byte code and pure lisp. Maybe the init time is= dominated by file access, rather then the processing those files.

Could it maybe be possible to create one .so per package = si that all functions from corresponding eln files is that .so? It could dr= astically reduce number of file access at load time. I don't know if it is = possible. 

Skickat fr=E5n min= Samsung Galaxy-smartphone.



-------- Originalmeddelande --------
Fr=E5n: Andrea Corallo <akrl@sdf.org>
Datum: 2020-01-01 19:42 (GMT+01:00)
Till: Stefan Monnier <monnier@iro.umontreal.ca>
Kopia: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
=C4mne: Re: On elisp running native

Stefan Monnier <monnier@iro.umontreal.ca> wr= ites:

> I think the focus should be on:
> - making it work everywhere
> - making it easy/convenient to use (e.g. even if you share your $HOME = between
>   different architectures or even different OSes as well as = different
>   versions of Emacs)

I think the natural action would be to move the eln in the build
directory (as these are in fact compiled).  Unfortunately this would n= ot
work with the elpa packages...  The other option would be to add a
suffix to the the eln file but is not nice at all.  Any idea?

Consider that now the situation is pretty bad because eln are likely not to be compatible even from different builds on the same codebase with
different configure parameters.

> As far as I'm concerned, support for a nil value of lexical-binding is=
> a non-goal (it should still work, of course, e.g. by using the
> bytecode): the dynbind version of Elisp is a legacy language and it's<= br> > better to update the code to lexbind than to try and make that legacy<= br> > code run faster.

Good I agree, and even if not that hard would be something more to care
about.

--
akrl@sdf.org

 --_000_VI1P194MB0429F3AF7407F4318D67FA5196200VI1P194MB0429EURP_--