From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Memory usage report Date: Fri, 18 Sep 2020 21:32:04 +0800 Message-ID: <87imcb43e3.fsf@localhost> References: <87lfh8kyot.fsf@gnus.org> <83k0ws5hzt.fsf@gnu.org> <87h7rwkxtk.fsf@gnus.org> <83imcb61p7.fsf@gnu.org> <871rizl5mf.fsf@gnus.org> <83r1qz48h3.fsf@gnu.org> <871rizjogr.fsf@gnus.org> <83pn6j45rr.fsf@gnu.org> <87wo0ri6kz.fsf@gnus.org> <83o8m34433.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="17028"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii , Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 18 15:34:27 2020 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 1kJGWx-0004Hf-9i for ged-emacs-devel@m.gmane-mx.org; Fri, 18 Sep 2020 15:34:27 +0200 Original-Received: from localhost ([::1]:38682 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJGWw-0004n9-AR for ged-emacs-devel@m.gmane-mx.org; Fri, 18 Sep 2020 09:34:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47264) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJGVi-00037x-6f for emacs-devel@gnu.org; Fri, 18 Sep 2020 09:33:10 -0400 Original-Received: from mail-pg1-x531.google.com ([2607:f8b0:4864:20::531]:42197) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kJGVg-00031R-DZ; Fri, 18 Sep 2020 09:33:09 -0400 Original-Received: by mail-pg1-x531.google.com with SMTP id k14so3477774pgi.9; Fri, 18 Sep 2020 06:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=6LWkiMK5vEAgH3f1rUDN7xTULEwGBzecLEZ6tckbew0=; b=uEtAtro6rCc01NQFrNPHyK4P2ExutzpE1hmBTkVulalr715oVfNgyFX2Iasgg1YHtk bQPWr39mww5ign3iyhZLvTTgz1hdduSutOyT4ERDAzVKgHJ/BgxWwkPCNni/0bOP0hHu 2grYXDakNWP37ONAfl1hsguAAtn8lX3tpSAh/PMR2lr/0960dT5VIdKBEH4FAn7vjcMe NNXHXxW0UnMMQI11tmKGXpJc4c92zq0yZyMQ+sR8TQLaChDj9RbSmrR6nd9TaqvN0cFk oHoc1ZidnL6G52xZW7fQCNJnHy/Sx6or2M0DJPCBz1Ej7FowSVow0vG6tsWSW2VWEdkV mdgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=6LWkiMK5vEAgH3f1rUDN7xTULEwGBzecLEZ6tckbew0=; b=eNcR/UOPEypMp9baLV4bM8jvJyPk9kbvLVeGmYHSn6iVs6zpzbZR+U/15aJ+kdgTXL J+WGyADfvXnDiW56Vq8tdXBOL+EnCa+o2MWzJ8zUSZt4zjBTVXn19xYJDdpWm5lNP0pP yludK2xUP/fJoPg+xcjkp0wo4a+ZAkz1V2beNLi+S2cHPILkLVu2Y+O9UuwD1MvAP29y HyW30PRmie8/WnzwmjR8W71QhwGpnUQQFFNteyj+2Lj98O7TxgW2qPHbvfjA5sFgoR1l dFw647bO/7X0gm16wkTUguO8aOug2MQWJqO+revoBsEJ5r41B9jpycL7+2yQbkp+Ya3G FbAw== X-Gm-Message-State: AOAM531T5cYqptcpNDbbvrgoGt1qZxj8RU9XQbw8gxjTYg0yTn7FJZU2 JJDTECUVUcKpR9G/g6Yn4M0dmkSZPXM8AZRO X-Google-Smtp-Source: ABdhPJxmmzIFJzkmYQiBS5J/XG66SHrIe5mQQCxTn8JxbuqMLebYLuVgt1yhtKIi7LjRuOVa9lDv0w== X-Received: by 2002:a63:1657:: with SMTP id 23mr3681223pgw.168.1600435986160; Fri, 18 Sep 2020 06:33:06 -0700 (PDT) Original-Received: from localhost ([104.250.131.79]) by smtp.gmail.com with ESMTPSA id gd14sm3050126pjb.0.2020.09.18.06.33.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2020 06:33:05 -0700 (PDT) In-Reply-To: <83o8m34433.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::531; envelope-from=yantar92@gmail.com; helo=mail-pg1-x531.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:256087 Archived-At: > I guess I don't understand the utility of knowing, e.g., which Lisp > string in the current session is the longest one. What would you do > with such information? Knowing a buffer with largest total memory occupied by buffer-local variables might be useful. Eli Zaretskii writes: >> From: Lars Ingebrigtsen >> Cc: emacs-devel@gnu.org >> Date: Fri, 18 Sep 2020 14:59:24 +0200 >> >> Eli Zaretskii writes: >> >> >> That can have significant memory? >> > >> > Some of them could, yes. >> >> Do you know which ones? > > bidi_cache, for one. > >> > Why would an image cache take that much? we flush it from time to >> > time, and I have difficulty believing that all those users reporting >> > large memory footprints load thousands of images every hour of every >> > day. >> >> It is unlikely that "all those users" use that many images, but some >> may. (As you no doubt remember, calling `image-size' in a loop will >> kill Emacs with an out of memory fault.) > > That loop is highly unlikely to happen in practice, certainly not > happen constantly in a long-lived session. > >> >> > Which variables did you have in mind in this context? Can you show an >> >> > example? >> >> >> >> It'd just traverse all the variables and compute the "largest" ones. >> > >> > Again, they are included in the GC report. So what do you expect to >> > see? >> >> I expect to see what variables take "all that size"? I'm not sure what >> you're asking here. > > I guess I don't understand the utility of knowing, e.g., which Lisp > string in the current session is the longest one. What would you do > with such information? > >> > So, while a more detailed report might be nice to have, I don't see >> > how it would help to diagnose "leaks" of the kind we are discussing >> > now on the bug list. >> >> I am not talking about any bug report in particular. If I were, that is >> where I would have posted this. > > Then I guess I don't understand the purpose of the features you'd like > to have. Can you explain?