From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Suppressing native compilation (short and long term) Date: Thu, 06 Oct 2022 09:33:43 +0300 Message-ID: <83pmf5qx4o.fsf@gnu.org> References: <87bkqxf1ij.fsf@tethera.net> <87y1ty9lha.fsf@gnus.org> <87lepym6ok.fsf@trouble.defaultvalue.org> <877d1i9h7k.fsf@gnus.org> <83edvqyr3q.fsf@gnu.org> <874jwl8e4p.fsf@gnus.org> <87pmf64beo.fsf@gnus.org> <87h70i4a46.fsf@gnus.org> <87czb648r9.fsf@gnus.org> <874jwi47l6.fsf@gnus.org> <87zgea2sgv.fsf@gnus.org> <87r0zm2qpl.fsf@gnus.org> <87ilky2khe.fsf@gnus.org> <87o7up26dr.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20407"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, rlb@defaultvalue.org, monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 06 08:42:53 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 1ogKaq-00052d-Af for ged-emacs-devel@m.gmane-mx.org; Thu, 06 Oct 2022 08:42:52 +0200 Original-Received: from localhost ([::1]:36932 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ogKao-0007db-Qn for ged-emacs-devel@m.gmane-mx.org; Thu, 06 Oct 2022 02:42:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44548) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogKS1-000534-Lr for emacs-devel@gnu.org; Thu, 06 Oct 2022 02:33:45 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55154) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogKRz-0004qi-5P; Thu, 06 Oct 2022 02:33:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=mSUb2YcO9hku85vFIc0tnIpXox4NH6i2gIhATfDCZr4=; b=FGXE58xrBu18 0GzrYrhMP3m+2Gkas1YxFlFudJxiox3fgHf4D8sO52NsAo25AQTXGW49mpFCZAp7WzZ81sdiAvu3j r82qSBQ3vT6UmMQWG6t4SokL7oM8Rplef0ioD3jwgDI+rGo7QJCEPWA/ApypYguxrOD3NSz73AkiJ aMJs6ek0YW7YJhgyFsY5ACgaDAHmMU81t2/ef/IfZjmCBsTNNLwKBPqNGFh9SlwnouQvH6ucsYCHh jyZfmhFdy4xd1o65KAtu11GFVaLQ6mg1h0nSkJ61D/BaLjYDKu9iQiTYd+4XD3d4F6jA9ySbCviTb G6UuokUy8f5S4E8Et0IUVw==; Original-Received: from [87.69.77.57] (port=2531 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogKRy-0005QH-I3; Thu, 06 Oct 2022 02:33:42 -0400 In-Reply-To: (message from Andrea Corallo on Thu, 06 Oct 2022 00:45:49 +0000) 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:297062 Archived-At: > From: Andrea Corallo > Cc: Eli Zaretskii , rlb@defaultvalue.org, > monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org > Date: Thu, 06 Oct 2022 00:45:49 +0000 > > > Which reminds me of another thing -- was there a reason that --batch > > implies "avoid most JIT compilation", like it does now, by the way? > > It's always seemed pretty odd to me, because JITting could well be quite > > useful when doing batch stuff, and there's no handy way to switch it on > > when doing --batch. > > The rational is that "tipically" batch executions are short in time, so > spawning there native async compilation would be a waste of cycles if > they do not complete in time. I think no one has statistical prove of > this, but the rational was at least discussed and I believe agreed here. Yes, we discussed that, and yes, we agreed. And I don't think the decision was wrong. For starters, it would be strange to delay exiting Emacs in batch so it could wait for the async compilation to complete. Moreover, in most cases waiting will not help, since the job of the batch invocation would have been long done anyway, so the produced *.eln files will not be loaded in time to make any difference. We do have batch commands to compile *.eln files explicitly (this is used when a release tarball is built). This was deemed to be enough, at least at the time we discussed these issues. I don't yet see why we'd need to revisit that decision. When does it cause problems?