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: [ELPA] New package: dired-duplicates Date: Thu, 02 Nov 2023 07:55:13 +0200 Message-ID: <83lebg8zsu.fsf@gnu.org> References: <875y2nugm8.fsf@posteo.net> <83edha9mlg.fsf@gnu.org> <87h6m5shpf.fsf@gmail.com> <831qd9a7gg.fsf@gnu.org> <87lebhz78r.fsf@posteo.net> <83sf5p8efg.fsf@gnu.org> <2b30b6e0-d30e-41e1-83a5-05b0c3fa8aa6@gmx.at> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17216"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philipk@posteo.net, visuweshm@gmail.com, emacs-devel@gnu.org To: Harald Judt Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 02 06:56:06 2023 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 1qyQgW-0004EY-Sn for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Nov 2023 06:56:05 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qyQft-0008QB-3Z; Thu, 02 Nov 2023 01:55:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qyQfr-0008Ph-Ap for emacs-devel@gnu.org; Thu, 02 Nov 2023 01:55:23 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qyQfq-0002zy-2J; Thu, 02 Nov 2023 01:55:22 -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=Tv31iKJrIp7Y6ftfNh977gtGEHffke+e6druXy3+mP8=; b=hkfWlj1b63HP Tk94oH8+zeOGASQWlx4VASNr4tNcA992l2NLW/NXz9MJmgouC/WFFy+ETYyhikeuOsFrEU6YkVarv gpvCLiz17mvZheBzJ+1a4DZaKHMka93hoetHRTnGxTmtLqRn1Fv5QIsN2kTQ0qfl7/Uz9nmm5nBMZ jtgZlK8A4HUQWudqujdA83GV71xn+v0O+xcpaaVsNaD7JO091CVsKyRbnqzhxZJVA2JoPVJTK2bX0 3908KCKnRShOJo3xA8+h4bu1el3HVEh/je7D8onPtZx1WqS3TaGo4VW0trTQMMbHRkKNErH1zhqp/ RNcdvDuPGv+xGtd9SMoQCA==; In-Reply-To: <2b30b6e0-d30e-41e1-83a5-05b0c3fa8aa6@gmx.at> (message from Harald Judt on Wed, 1 Nov 2023 21:09:48 +0100) 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:312106 Archived-At: > Date: Wed, 1 Nov 2023 21:09:48 +0100 > Cc: visuweshm@gmail.com, emacs-devel@gnu.org > From: Harald Judt > > Thanks for the numbers. What troubles me a bit more than the speed is which > effects inserting such a large file into a buffer has memory-wise? It is IMO okay to fail when sha256sum is not available and a file is larger than the available VM, so Emacs runs out of memory, if this is the situation that worries you. But these cases should be relatively rare, and so there's no reason to fail to have this feature in the much more frequent case that the files are not as large as the available VM. If the file can be read by Emacs, even if it's large, then killing the buffer after computing the hash should not have any adverse effects on memory usage of that Emacs session.