From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4232 invoked by alias); 23 May 2017 15:49:11 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 41143 Received: (qmail 5882 invoked from network); 23 May 2017 15:49:11 -0000 X-Qmail-Scanner-Diagnostics: from 195.159.176.226 by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(195.159.176.226):SA:0(2.7/5.0):. Processed in 2.061308 secs); 23 May 2017 15:49:11 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: ** X-Spam-Status: No, score=2.7 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, NML_ADSP_CUSTOM_MED,RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Envelope-From: gcszd-zsh-workers@m.gmane.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at m.gmane.org does not designate permitted sender hosts) X-Injected-Via-Gmane: http://gmane.org/ To: zsh-workers@zsh.org From: Christian Neukirchen Subject: Re: High memory usage on // substitution in one situation, normal usage in other Date: Tue, 23 May 2017 17:33:17 +0200 Message-ID: <87bmqjk2pu.fsf@gmail.com> References: <170521130349.ZM4506@torch.brasslantern.com> <201705212227360937.046E4951@gateway.core.mpy.ch> <170521164322.ZM5074@torch.brasslantern.com> <1495443021.3874316.984296144.5B695DB8@webmail.messagingengine.com> <170522080040.ZM7679@torch.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@blaine.gmane.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) In-Reply-To: <170522080040.ZM7679@torch.brasslantern.com> (Bart Schaefer's message of "Mon, 22 May 2017 08:00:40 -0700") Bart Schaefer writes: > On May 22, 8:50am, Daniel Shahaf wrote: > } > } > 1.8MB/2*(the number of zeroes in all integers from 1 to 200000), > } > } 88894 > } > } (So we can compute the exact predicted memory use and compare it to the > } observed use.) > > I'd be surprised to find that anyone has a machine with 80GB of virtual > memory that it's worth dedicating to testing this. (Also that's a really > rough estimate, could be low by as much as a factor of six.) Challenge accepted. ;) (The machine idles anyway...) Linux deka 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27 15:29:09 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux zsh 5.1.1 (x86_64-ubuntu-linux-gnu) with EXTENDEDGLOB on: PID USER PRI - - NI VIRT RES SHR S CPU% MEM% TIME+ Command 2841 neukirche 20 - - 0 81.4G 77.7G 3064 R 99.8 58.1 8:05.40 zsh big 2841 neukirche 20 - - 0 82.1G 75.9G 2872 R 18.5 56.8 8:26.14 zsh big 2841 neukirche 20 - - 0 87.7G 80.8G 2872 R 99.8 60.5 9:58.80 zsh big 2841 neukirche 20 - - 0 91.2G 84.3G 2872 R 99.7 63.1 11:01.29 zsh big 2841 neukirche 20 - - 0 93.5G 85.3G 2872 R 100. 63.8 11:54.64 zsh big 2841 neukirche 20 - - 0 95G 85.7G 2872 R 99.7 64.1 12:49.51 zsh big 2841 neukirche 20 - - 0 97G 86.2G 2872 R 99.7 64.5 13:45.90 zsh big 2841 neukirche 20 - - 0 100G 86.8G 2872 R 99.7 65.0 15:14.28 zsh big 2841 neukirche 20 - - 0 102G 87.4G 2664 R 100. 65.4 16:24.38 zsh big 2841 neukirche 20 - - 0 105G 88.0G 2664 R 99.7 65.9 17:45.16 zsh big 2841 neukirche 20 - - 0 107G 88.8G 2664 R 99.0 66.4 19:09.09 zsh big 2841 neukirche 20 - - 0 109G 89.3G 2664 R 99.5 66.8 20:26.41 zsh big 2841 neukirche 20 - - 0 116G 93.5G 2664 R 99.0 70.0 24:52.41 zsh big 2841 neukirche 20 - - 0 118G 92.5G 2664 D 43.4 69.3 27:12.57 zsh big 2841 neukirche 20 - - 0 122G 95G 2664 R 100. 71.4 30:23.67 zsh big 2841 neukirche 20 - - 0 128G 98G 2664 R 30.8 73.7 39:08.38 zsh big 2841 neukirche 20 - - 0 132G 101G 2640 R 99.7 75.7 47:25.95 zsh big Then the box started to swap as it only has 134G RAM, and I stopped it. Perhaps the result is interesting nevertheless. -- Christian Neukirchen http://chneukirchen.org