On 2023-11-09 at 09:43, Eli Zaretskii wrote:>> Date: Thu, 9 Nov 2023 09:00:11 
+0100
>> Cc: emacs-devel@gnu.org
>> From: Harald Judt <h.judt@gmx.at>
>>
>>> The size limitation should have its default value dependent on whether
>>> the build is a 32-bit (which we still support) or 64-bit.  You can
>>> look at how we compute treesit-max-buffer-size, to figure out how to
>>> express the conditions for the default value.
>>
>> Yes, but I wonder, why do this? There can be 32-bit systems as well as 64-bit
>> systems that can have only 2GiB RAM, both might fail when trying to open a
>> file that has e.g. 1536MiB. Then, there might be both types of systems that
>> have 8gb of RAM that can open such files with no problems?
> 
> If you are saying that we can do with a single value, I'm okay with
> that, provided that this value will be accepted by users.  32-bit
> systems cannot have buffers larger than 2 GiB, and a reasonable limit
> would be something like 500 MiB, I think.  This could be too low for
> users of 64-bit systems, but if it's okay, it's fine with me.  Your
> proposed default, 1 GiB, is too large for a typical 32-bit system,
> IMO.
> 
>> Maybe it would be possible to make it dependent on the amount of RAM available
>> on the system?
> 
> Ideally, yes, but in practice knowing how much is available is not
> that easy on a modern OS, so I don't think it's worth the hassle,
> especially in fallback code.

I agree, 500M for 32-bit and 1G for 64-bit are good defaults for the 
dired-duplicates use-case, I guess most typical systems will be able to handle 
it. I will implement it this way.

Harald

-- 
`Experience is the best teacher.'

PGP Key ID: 4FFFAB21B8580ABD
Fingerprint: E073 6DD8 FF40 9CF2 0665 11D4 4FFF AB21 B858 0ABD