From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: chad Newsgroups: gmane.emacs.devel Subject: Re: Time to merge scratch/correct-warning-pos into master, perhaps? Date: Wed, 26 Jan 2022 11:56:30 -0500 Message-ID: References: <835yq9ls7j.fsf@gnu.org> <058b682b11240176288f@heytings.org> <83h79tjd2f.fsf@gnu.org> <058b682b11f58780b580@heytings.org> <83v8y8ij39.fsf@gnu.org> <6a5bb5a08b3d764611f9@heytings.org> <87o83z5tfa.fsf@telefonica.net> <87ee4vmhh1.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000013a80205d67f1601" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34173"; mail-complaints-to="usenet@ciao.gmane.io" To: EMACS development team Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 26 18:22:37 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 1nCm0B-0008fI-TK for ged-emacs-devel@m.gmane-mx.org; Wed, 26 Jan 2022 18:22:36 +0100 Original-Received: from localhost ([::1]:59118 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nCm0A-0006tO-Kz for ged-emacs-devel@m.gmane-mx.org; Wed, 26 Jan 2022 12:22:34 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35800) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nClbD-0003en-WF for emacs-devel@gnu.org; Wed, 26 Jan 2022 11:56:48 -0500 Original-Received: from mail-lj1-f169.google.com ([209.85.208.169]:37438) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nClbB-0007Fr-Ld for emacs-devel@gnu.org; Wed, 26 Jan 2022 11:56:47 -0500 Original-Received: by mail-lj1-f169.google.com with SMTP id z7so507775ljj.4 for ; Wed, 26 Jan 2022 08:56:44 -0800 (PST) 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; bh=fx6U9koIkCI1QfpA3mnr7XbbqAHunJSzSuRNZ5xSFrs=; b=Kt0asigvbSseURKUqOJrlk3I9NL3865yBd2sc8sRd7fP5Aspacx+6SMghe4jBL/W6N ZToAl8uJy4TuYuaBiTHVvYtgkCk0LOckT5SptTUwXhBiJ/f/4RryCqIYCqXDRRL2Fkri 36MKyz7FJO/0xV5puKghazZHilLtQiuA+BRLur9UVBxMfKMbtS/zg6wv5YUltfbFi4f8 MrUO5YlYibeF+RBwQ81Nq9B7UPfc6xFTbr04uAuetw+NMlZemJIIxoqrtLZeC99elNq5 bae2iR338VblTPvn7lDM/TeHnbTSSzDqHD+cO4+Fg3xBuWQqB1izxXyb2RXyDwjgWua5 g29A== X-Gm-Message-State: AOAM5316zglYbSgn6Gb5Dg9wwZ/DEUTtJs6ShyJ0LECMWycRqLZG5do0 1xORrYS+vzgew10Df8LmTLT01LV37h1nK5O65MMujoK80uc= X-Google-Smtp-Source: ABdhPJzFEhCEWAsBgX2pPCwmRty0z3rHGKT65QRrxONzeO1kN5I1A1KrnMbLlBPa2BVlYkQNFJT5vvrWe1ai3p3RV7M= X-Received: by 2002:a2e:a361:: with SMTP id i1mr12278ljn.146.1643216203129; Wed, 26 Jan 2022 08:56:43 -0800 (PST) In-Reply-To: <87ee4vmhh1.fsf@yahoo.com> Received-SPF: pass client-ip=209.85.208.169; envelope-from=yandros@gmail.com; helo=mail-lj1-f169.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:285436 Archived-At: --00000000000013a80205d67f1601 Content-Type: text/plain; charset="UTF-8" Since changing careers a long while back, I don't get much in-depth hacking done anymore, but in my current situation, I do spend a fair bit of time collaborating remotely across time zones and specialties (especially creative, analytic, and experience-focused people). I think maybe I can help here; apologies if not. On Tue, Jan 25, 2022 at 8:09 someone wrote: > I think bikeshedding is over a claim that the new feature (which finally > makes byte compiler warnings accurate) slows down Emacs by a dozen or so > percent. > I don't understand at all what this message is trying to say, and I'll wager that I'm not alone. (I've removed the name, because this isn't about a person; it's about the discussion.) There is a proposal being considered that improves emacs by adding a long-missing capability that _at least_ some people find potentially very useful, even if the capability isn't 100%. (I understand from conversation here that it will occasionally be wrong, but nearly always be right or very close to right.) There is also a performance cost for this capability. There is also some high-level agreement from the maintainers that the capability will be seriously considered as long as the cost isn't too high, and there are some *very rough* guidelines for that acceptable cost. This is quite good -- it's basically impossible to predict these costs, and it's difficult to even measure them after the fact, much less beforehand. Additionally, it's entirely possible that the costs can be mitigated once they are identified. I think we all understand that the final decision will be made by the maintainers, with input from the users and developers (with all of the possible side-effects like maintaining a branch, fork, etc). Towards that end, the best way to move forward (from what I can see) is twofold: 1.) identify the costs, including a reasonable level of detail THEN 2.) determine, for various use-cases (users, situations, platforms, etc.) whether than cost is too high or not. Trying to jump to #2 is very common, natural, and in fact difficult for humans to avoid, but it almost never helps, and it quite frequently hinders the effort (I think there are clear examples of that here). This is, unfortunately, even more likely to be true in the current emacs-devel environment, where I claim there are clear issues of ego, tradition, process, and personality that are likely (have already) to be become entangled. This is common in the best of times, and it's very rare that I talk to another human today who thinks that these are the best of times. To that end, I suggest that people try to focus on step 1 above: identify the costs, including when and where (i.e. platforms, circumstance, and use-cases) where emacs is slower with this capability added. We know that byte-compiling is slower, so just finding/noting that is presumably done, but it seems there might be some questions about why (e.g. the recent sub-thread about EQ(Qnil,...) vs NILp(). I'm sure there are more measurements that can be done there, but perhaps it would be best to try to analyze the hot paths in byte-compiling using the new capability, to see if there are ways to mitigate it? There is also concern that emacs is slower outside of byte-compiling, but the reported numbers there are divergent, and it seems that we haven't even established a vector (or set of vectors?) for comparison. This seems like a pretty good first step. (Yes, benchmarking emacs is hard, but we don't need a perfect approach for this. A few "good" metrics should do the job for this capability.) There is an outstanding question of whether or not to merge the capability into the development head, to get more people involved in testing and refinement. Again, this is a question for the maintainers. I will hazard a guess that they would like to see a bit more forward motion of how to measure the costs first, but I could be wrong. In either case, it seems like there is enough interest that if someone were to put together some candidate benchmarks, and there were reasonable buy-in that the candidates were solid, we could probably get people to run some tests from the branch. That would probably (I'm guessing here) be enough to make a clear call between "needs more baking" and "we can try this on git master". If someone does have ideas for such benchmarks, please suggest them (here, the elpa package, etc.) and I'm sure we'll be able to get people to try them in various contexts. I hope that helps! If not, then I hope at least it gets us moving forward. ~Chad --00000000000013a80205d67f1601 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Since changing careers a long while back, I don't get much in-depth ha= cking done anymore, but in my current situation, I do spend a fair bit of t= ime collaborating remotely across time zones and specialties (especially cr= eative,=C2=A0 analytic, and experience-focused people). I think maybe I can= help here; apologies if not.


On Tue, Jan= 25, 2022 at 8:09 someone wrote:
I think bikeshedding is over a claim that the new feature = (which finally
makes byte compiler warnings accurate) slows down Emacs b= y a dozen or so
percent.

I don= 't understand at all what this message is trying to say, and I'll w= ager that I'm not alone. (I've removed the name, because this isn&#= 39;t about a person; it's about the discussion.)

There is a proposal being considered that improves emacs by adding a lon= g-missing capability that _at least_ some people find potentially very usef= ul, even if the capability isn't 100%. (I understand from conversation = here that it will occasionally=C2=A0be wrong, but nearly always be right or= very close to right.) There is also a performance cost for this capability= .=C2=A0

There is also some high-level agreement fr= om the maintainers that the capability will be seriously considered as long= as the cost isn't too high, and there are some *very rough* guidelines= for that acceptable cost. This is quite good -- it's basically impossi= ble to predict these costs, and it's difficult to even measure them aft= er the fact, much less beforehand. Additionally, it's entirely possible= that the costs can be mitigated once they are identified.=C2=A0
=
I think we all understand that the final decision will be ma= de by the maintainers, with input from the users and developers (with all o= f the possible side-effects like maintaining a branch, fork, etc). Towards = that end, the best way to move forward (from what I can see) is twofold:

1.) identify the costs, including a reasonable level= of detail
THEN
2.) determine, for various use-cases (u= sers, situations, platforms, etc.) whether than cost is too high or not.

Trying to jump to #2 is very common, natural, and in= fact difficult for humans to avoid, but it almost never helps, and it quit= e frequently hinders the effort (I think there are clear examples of that h= ere). This is, unfortunately, even more likely to be true in the current em= acs-devel environment, where I claim there are clear issues of ego, traditi= on, process, and personality that are likely (have already) to be become en= tangled. This is common in the best of times, and it's very rare that I= talk to another human today who thinks that these are the best of times.

To that end, I suggest that people try to focus on = step 1 above: identify the costs, including when and where (i.e. platforms,= circumstance, and use-cases) where emacs is slower with this capability ad= ded.=C2=A0

We know that byte-compiling is slower, = so just finding/noting that is presumably done, but it seems there might be= some questions about why (e.g. the recent sub-thread about EQ(Qnil,...) vs= NILp(). I'm sure there are more measurements that can be done there, b= ut perhaps it would be best to try to analyze the hot paths in byte-compili= ng=C2=A0using the new capability, to see if there are ways to mitigate it?<= /div>

There is also concern that emacs is slower outside= of byte-compiling, but the reported numbers there are divergent, and it se= ems that we haven't even established a vector (or set of vectors?) for = comparison. This seems like a pretty good first step. (Yes, benchmarking em= acs is hard, but we don't need a perfect approach for this. A few "= ;good" metrics should do the job for this capability.)

<= /div>
There is an outstanding question of whether or not to merge the c= apability into the development head, to get more people involved in testing= and refinement. Again, this is a question for the maintainers. I will haza= rd a guess that they would like to see a bit more forward motion of how to = measure the costs first, but I could be wrong. In either case, it seems lik= e there is enough interest that if someone were to put together some candid= ate benchmarks, and there were reasonable buy-in that the candidates were s= olid, we could probably get people to run some tests from the branch. That = would probably (I'm guessing here) be enough to make a clear call betwe= en "needs more baking" and "we can try this on git master&qu= ot;.

If someone does have ideas for such benchmark= s, please suggest them (here, the elpa package, etc.) and I'm sure we&#= 39;ll be able to get people to try them in various contexts.

=
I hope that helps! If not, then I hope at least it gets us movin= g forward.
~Chad


--00000000000013a80205d67f1601--