From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Tooltips GC overhead Date: Fri, 07 Aug 2015 10:52:34 -0400 Message-ID: References: <55B7796B.3070005@gmx.at> <55B87E3F.80708@gmx.at> <55B8E367.9020201@cs.ucla.edu> <55B8F3E9.5000707@gmx.at> <833806yld0.fsf@gnu.org> <55B915CE.7070803@gmx.at> <55B94267.5050208@cs.ucla.edu> <55BCA454.6050208@gmx.at> <83egjkv2st.fsf@gnu.org> <83twsfu6b5.fsf@gnu.org> <83si7ztc6y.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1438959192 18850 80.91.229.3 (7 Aug 2015 14:53:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Aug 2015 14:53:12 +0000 (UTC) Cc: rudalics@gmx.at, eggert@cs.ucla.edu, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 07 16:52:59 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZNj10-000426-Hz for ged-emacs-devel@m.gmane.org; Fri, 07 Aug 2015 16:52:58 +0200 Original-Received: from localhost ([::1]:49458 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNj0z-00045X-JW for ged-emacs-devel@m.gmane.org; Fri, 07 Aug 2015 10:52:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47594) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNj0m-000459-JL for emacs-devel@gnu.org; Fri, 07 Aug 2015 10:52:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZNj0i-0007NZ-AT for emacs-devel@gnu.org; Fri, 07 Aug 2015 10:52:44 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:23585) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNj0e-0007Ga-GU; Fri, 07 Aug 2015 10:52:36 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A2FgA731xV//gFNJ1SCoMQhAKFVcMLBAICgTw8EQEBAQEBAQGBCkEFg10BAQMBViMFCws0EhQYDSSINwjPIwEBAQEGAgEfizqEKF0HhC0FhmiFd6glI4Fmgi4igngBAQE X-IPAS-Result: A0A2FgA731xV//gFNJ1SCoMQhAKFVcMLBAICgTw8EQEBAQEBAQGBCkEFg10BAQMBViMFCws0EhQYDSSINwjPIwEBAQEGAgEfizqEKF0HhC0FhmiFd6glI4Fmgi4igngBAQE X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="159084459" Original-Received: from 157-52-5-248.cpe.teksavvy.com (HELO pastel.home) ([157.52.5.248]) by ironport2-out.teksavvy.com with ESMTP; 07 Aug 2015 10:52:35 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 00E6E604CF; Fri, 7 Aug 2015 10:52:34 -0400 (EDT) In-Reply-To: <83si7ztc6y.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 04 Aug 2015 16:28:37 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:188548 Archived-At: > Just looking at the implementation of Fcons, I find it hard to believe > a single comparison can have any significant effect on its efficiency. > So I'm unsure how this could be of any practical concern. Fcons is a core operation executed fairly frequently, so any slowdown (no matter how small) needs to be justified by a major advantage. Making the allocation profiler (which so far has never been useful to anyone, AFAICT) slightly more precise, is not obviously a "major advantage". At the very least, I'd need positive proof that the extra precision has been useful at least once. >> > In any case, it's much better than the current useless profile. >> I'm not convinced it'd make it sufficiently better > Well, it allowed me in this case to identify the source of the problem > quickly, efficiently, and accurately. IIUC, something *else* allowed you to do that. I don't think anyone has actually tried to improve the precision of the allocation profiler and found it to help in this case. It's quite possible that some other problems might still prevent it from being useful in this case. >> I'd be OK with adding this "more precise allocation profiler" as >> a compile-time option, so we could at least see if the improved >> precision does make it more useful. > IME, compile-time options of this kind are rarely useful, because they > are never there when you need them. Especially if the person who > needs to perform measurements doesn't build their Emacs. Until I have positive proof that the extra precision is useful in some cases, I'll reject such changes in the default build. So it's either "rejected" or "depends on a compile-time option" for now. Stefan