From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: How to add pseudo vector types Date: Thu, 22 Jul 2021 21:29:02 +0200 Message-ID: <874kcmi1vl.fsf@telefonica.net> References: <83h7gw6pyj.fsf@gnu.org> <45EBF16A-C953-42C7-97D1-3A2BFEF7DD01@gmail.com> <83y2a764oy.fsf@gnu.org> <83v95b60fn.fsf@gnu.org> <00DD5BFE-D14E-449A-9319-E7B725DEBFB3@gmail.com> <83r1fz5xr9.fsf@gnu.org> <1AAB1BCC-362B-4249-B785-4E0530E15C60@gmail.com> <83czri67h0.fsf@gnu.org> <46BBFF88-76C3-4818-8805-5437409BEA93@gmail.com> <83wnpq46uk.fsf@gnu.org> <533BD53B-4E85-4E9E-B46A-346A5BBAD0F5@gmail.com> <258CB68D-1CC1-42C8-BDCD-2A8A8099B783@gmail.com> <1a776770-50b7-93cd-6591-c9a5b3a56eb8@gmail.com> <8335s64v10.fsf@gnu.org> <5380C92B-6C15-4490-A1E0-1C3132DBB16A@gmail.com> <878s1yigle.fsf@telefonica.net> <83im122s2n.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19486"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: emacs-devel@gnu.org Cancel-Lock: sha1:Gn31unQlkjUSHEyhNEjjHtaKhfM= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jul 22 21:32:10 2021 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 1m6eQT-0004qW-5t for ged-emacs-devel@m.gmane-mx.org; Thu, 22 Jul 2021 21:32:09 +0200 Original-Received: from localhost ([::1]:50676 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m6eQS-0007XO-4F for ged-emacs-devel@m.gmane-mx.org; Thu, 22 Jul 2021 15:32:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47962) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m6eNp-0005lo-Jo for emacs-devel@gnu.org; Thu, 22 Jul 2021 15:29:25 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:38592) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m6eNn-0007oT-HZ for emacs-devel@gnu.org; Thu, 22 Jul 2021 15:29:25 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1m6eNe-0000zX-LM for emacs-devel@gnu.org; Thu, 22 Jul 2021 21:29:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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.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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:271475 Archived-At: Eli Zaretskii writes: >> Of course those parameters would be configurable on Emacs, but disabling >> TS on a 2MB file because it uses 20MB is way too conservative, IMHO. > > Why would we limit ourselves to 20MB? uint32_t supports upto 4GB. I didn't suggest that we should limit ourselves to 20MB, I observed that current machines have enough resources for handling large files ("large" meaning "big enough to keep me busy reading for some years.") >> Guys, you are speculating too much about minutia and worst-case >> scenarios. (Do we really care about TS not supporting files larger than >> 4GB? I mean, REALLY?) > > Yes, we do. For at least 2 reasons: (a) source code files produced by > programs can be very large; I know, I work with machine-generated (read: code-dense) 20+MB C++ files on a regular basis. However, I wouldn't agree on renouncing to useful features because they could be problematic when dealing with large files. That is, it would be a mistake to discard TS as inadequate for Emacs just because it doesn't benefit (and I say "not benefit", not "penalise") certain use cases. > (b) having a feature that fails before you > reach the max size of a buffer Emacs supports is a problem, because it > will cause hard-to-deal-with problems. We can put reasonable limits on when to use TS once we have some experience with it. What matters right now is if TS would be usable for the typical use case, and I guess the answer is positive. Also, it is not as if we had other options to consider. >> I'll rather focus on implementing the thing and optimize later. My bet >> is that a crude implementation would work fine for the 99% of the users >> and be an improvement over what we have now on practically all cases. > > This is not a prototype project. (Or at least I hope it won't end up > being that.) This is supposed to be the industry-strength code that > core Emacs will use for the years to come to support features which > need language-dependent parsing. It cannot work correctly only in 99% > of use cases. So we must assess the limitations seriously and plan > ahead for them. I said "would work *fine* for the 99% of users", this does not imply that it would work incorrectly for the rest. On the "planning ahead" part, TS support would be an optional, quasi-external feature for some time, it is not as if it comes out with some critical bug Emacs would become unusable. TS support can be fine-tuned without disrupting the rest of Emacs development. If, on the other hand, we start making changes on Emacs' internals for allowing some TS-related optimizations (even when we don't know if they are neccessary at all) that could be a destabilizing move for Emacs as a whole. Apart from delaying TS support. >> BTW, a 10x AST/source-code size ratio is quite reasonable. > > It could be, but please don't forget that this is _in_addition_to_ the > "normal" Emacs memory footprint, and that could easily be 1GB and > sometimes several times that. Yes, but if you want something you need to pay something, and you can hardly get TS' features with less than that. At least for complex languages like C++. Talking about scenarios of heavy memory usage, I'll comment in passing that in my recent experience, once Emacs exceeds 2GB the gc pauses start to be so annoying that I don't care anymore about how much memory an external tool would use if it works fast enough.