From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: On elisp running native Date: Thu, 02 Jan 2020 11:31:31 +0000 Message-ID: References: <83tv5mp48l.fsf@gnu.org> <83sgl0lchm.fsf@gnu.org> <83imlwl9vm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="84040"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: Eli Zaretskii , Stefan Monnier , "emacs-devel@gnu.org" To: arthur miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 02 12:31:43 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 1imyha-000LjF-WC for ged-emacs-devel@m.gmane.org; Thu, 02 Jan 2020 12:31:43 +0100 Original-Received: from localhost ([::1]:39982 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1imyhZ-0008Ro-K0 for ged-emacs-devel@m.gmane.org; Thu, 02 Jan 2020 06:31:41 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44849) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1imyhT-0008Re-Bd for emacs-devel@gnu.org; Thu, 02 Jan 2020 06:31:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1imyhS-00020P-4A for emacs-devel@gnu.org; Thu, 02 Jan 2020 06:31:35 -0500 Original-Received: from mx.sdf.org ([205.166.94.20]:54833) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1imyhR-0001z2-TW; Thu, 02 Jan 2020 06:31:34 -0500 Original-Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 002BVXr3016345 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO); Thu, 2 Jan 2020 11:31:33 GMT Original-Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 002BVWVp003468; Thu, 2 Jan 2020 11:31:32 GMT In-Reply-To: (arthur miller's message of "Thu, 2 Jan 2020 07:55:27 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 205.166.94.20 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:243857 Archived-At: arthur miller writes: > 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. Thanks for the feedback, is cool to know that somebody reproduced. > I didn't see any speedup on load time, either with -Q > flag, or when I loaded my init files and packages. I have complied 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 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 > functions from corresponding eln files is that .so? It could drastically > reduce number of file access at load time. I don't know if it is > possible. I have no evidence that using eln is faster or slower than elc in terms of load time. What you suggest is easily possible from the compiler point of view but how should it behave exactly? We probably would need some notion of package then? Anyway I'd like to point out that: - Mosts are likely to be compiling at speed 0 for now, and this translate into considerably bigger elns (not sure this has an impact). - We should profile the load process first to understand were we spend time. But I'm not sure we are at this stage of refinement. Andrea -- akrl@sdf.org