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: Sat, 19 Sep 2020 23:45:37 +0800 Message-ID: <87h7rtepni.fsf@localhost> References: <87lfh8kyot.fsf@gnus.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> <87imcb43e3.fsf@localhost> <83k0wr4222.fsf@gnu.org> <87ft7f40p8.fsf@localhost> <83h7rv3xsc.fsf@gnu.org> <87wo0rdpud.fsf@localhost> <838sd6522b.fsf@gnu.org> <87tuvuehhq.fsf@localhost> <83wo0q2ohm.fsf@gnu.org> <87mu1lesy3.fsf@localhost> <83d02h3jj2.fsf@gnu.org> <87k0wper2r.fsf@localhost> <83a6xl3hji.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="24295"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 19 17:54:39 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 1kJfCB-0006Dt-GM for ged-emacs-devel@m.gmane-mx.org; Sat, 19 Sep 2020 17:54:39 +0200 Original-Received: from localhost ([::1]:48026 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJfCA-0001mT-Ii for ged-emacs-devel@m.gmane-mx.org; Sat, 19 Sep 2020 11:54:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48510) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJf4Z-0002uw-J5 for emacs-devel@gnu.org; Sat, 19 Sep 2020 11:46:47 -0400 Original-Received: from mail-qk1-x72f.google.com ([2607:f8b0:4864:20::72f]:35749) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kJf4W-0005kG-V0; Sat, 19 Sep 2020 11:46:47 -0400 Original-Received: by mail-qk1-x72f.google.com with SMTP id q5so10144931qkc.2; Sat, 19 Sep 2020 08:46:43 -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=ErokjIKbt6cY6txzo1zwUY/DTc82fv0tf9jjaeWRI9I=; b=oHkSOVGv6DY7Mzjez5JvOzcwpjHH+WDYtsgk9nYTfhYxuNNZFTU7CvRCXswYluwva1 RgPLB6Aet1ykEmul9HZPSVisU4RpMb2tbh6mdTvyTLJx4Iy8cdHdzCjLop9W3Rzg2i07 sfK61DEAmGSogdujs7YNXaAsICqsZpS3+JwThT2USUliBKGb2yK9fVb1RWWTWZ0e1CXU ILDCAZ+Amke1LF7C6+pvDV67vi/op2Sm2k9iiMGcBHt8CmRaxdGIouVavjEYe5S+pkcG 86+zdewP2H+zB4wVTXWSPTG978OPnqVxsGLzZuQNlD6j9ftGV/8i7uNIEXYF1x7P42of vUCA== 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=ErokjIKbt6cY6txzo1zwUY/DTc82fv0tf9jjaeWRI9I=; b=Hw/60bulG7jcDV0FqdiGQI3tUqfdd2YnE43jhSY6vlUNRAPOke3ZvngvEmONYWgLGG loiDzLs7Hjv0dfZIujCNUTBfpLIHosV4prD7T9jYu8Rj5g0aQPa59KCe3uuoccTtYxUt B2WKhQmNuF525AuHKukI01iW+n7cIE/dd+OezwcIwdVKJMiLwsOjT/vsr8HchlYZan4E hLg6L9tw1YA2H//3j/2SC5tb4NtZIF+rphKcmh2u2xe2mk3LxWPxcaLajzRGn1XAnQL8 L5OIAfC93q3PefmEzkh81QLFl6dkJ5aid1LPkuSPcsCjEBCdH23376qizYNARDXRCJAA 9gyg== X-Gm-Message-State: AOAM533V/75xMjaztu44pG6hng6/cfHTdE4c1UvG/lEnKlychRIzEWGe DZN2t7aUY7/BZMnu69EYRlE2o4FRYeQ= X-Google-Smtp-Source: ABdhPJyviV80qAvX40Rr7lC+dPSFx1uWTS03+vVjBsBdXkG9ASAb1GxC/yEieIyKYzEdEg6QjNTlRw== X-Received: by 2002:a37:6481:: with SMTP id y123mr37991162qkb.464.1600530402053; Sat, 19 Sep 2020 08:46:42 -0700 (PDT) Original-Received: from localhost ([208.167.241.222]) by smtp.gmail.com with ESMTPSA id t43sm4754538qtc.54.2020.09.19.08.46.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 19 Sep 2020 08:46:41 -0700 (PDT) In-Reply-To: <83a6xl3hji.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::72f; envelope-from=yantar92@gmail.com; helo=mail-qk1-x72f.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:256191 Archived-At: >> Some of the overlays and text properties are not strictly necessary. >> For example, text properties are sometimes used as cache to avoid >> parsing text multiple times. Is the resulting speedup worth extra memory >> usage? It is not clear since we do not have an easy way to determine the >> extra memory usage. > > These are exactly the questions to ask the Org developers, I think. As an org developer, how can I know the extra memory usage by that one specific type of text properties? > What that profiler counts is calls to memory-allocation functions, > that's all. Without being able to account for memory which was freed > after being allocated, these counts are useless. Got it. Then, I imagine that a simple delta of before/after running a function could be used to build a more useful memory report. Current GC report only provides the total usage, but no information on how individual function calls increased the memory usage. This might even be done in Elisp comparing `cons-cells-consed' and similar variables before/after each function call. Best, Ihor Eli Zaretskii writes: >> From: Ihor Radchenko >> Cc: larsi@gnus.org, emacs-devel@gnu.org >> Date: Sat, 19 Sep 2020 23:14:52 +0800 >> >> > I think the more useful question is: are all those overlays and text >> > properties necessary? If they are, they take the memory they are >> > supposed to take. >> >> Some of the overlays and text properties are not strictly necessary. >> For example, text properties are sometimes used as cache to avoid >> parsing text multiple times. Is the resulting speedup worth extra memory >> usage? It is not clear since we do not have an easy way to determine the >> extra memory usage. > > These are exactly the questions to ask the Org developers, I think. > >> > If you mean memory used by non-Lisp objects, I don't see how we could >> > produce that without having infrastructure for tracking memory >> > allocation, something that debugging malloc libraries already do. >> >> Hmm. I am looking again at the profiler-report output. It seems to >> report the memory allocation for individual function calls (that's what >> I meant by "real" memory profiler). Do I miss something? > > What that profiler counts is calls to memory-allocation functions, > that's all. Without being able to account for memory which was freed > after being allocated, these counts are useless.