From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alex Gramiak Newsgroups: gmane.emacs.devel Subject: Re: NS port: How to debug excessive garbage collection? Date: Sat, 13 Apr 2019 15:41:22 -0600 Message-ID: <87lg0dtwfx.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="40691"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Keith David Bershatsky Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 13 23:41:41 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hFQP7-000AUo-5S for ged-emacs-devel@m.gmane.org; Sat, 13 Apr 2019 23:41:41 +0200 Original-Received: from localhost ([127.0.0.1]:56219 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hFQP5-0003sK-Ba for ged-emacs-devel@m.gmane.org; Sat, 13 Apr 2019 17:41:39 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40073) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hFQOz-0003s3-6Q for emacs-devel@gnu.org; Sat, 13 Apr 2019 17:41:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hFQOy-0002ap-65 for emacs-devel@gnu.org; Sat, 13 Apr 2019 17:41:33 -0400 Original-Received: from mail-pf1-x433.google.com ([2607:f8b0:4864:20::433]:33748) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hFQOw-0002S0-HA; Sat, 13 Apr 2019 17:41:30 -0400 Original-Received: by mail-pf1-x433.google.com with SMTP id h5so6784315pfo.0; Sat, 13 Apr 2019 14:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=+OxvmTBB8+o117GHLPuXzP0Xd6JDKHisPtYSehOTr9Q=; b=siVv+DhwIAgc5w+ZOS+oUEdNBvEOfj0hTU9Pbc60rYEQYKK1rVsBKyCM9Uoe/829Tq Z0trobT6JC/2k9/ojQzBtBSnOdoyiIvim5vAnNKUVNu1j0LlZZJIl+spDwD9r2a2AGHW mk31nzavJL7c3gqHM3PsuR3eMAvQwQcju2mZrgr14Iy0I5iKfBHRbsTCtbAubSmYvyRa zZZh46SNLzjwKWpsgxeCSqBzMLP7hvHlbDjjcboTXLHmDgwsOQawTqCK5W8FmqRD788g wyVVgh9qTWVMF7oIhI4W1neWDfZmRSFu1FbdAtpAB5f58jTvMqv5Ep+9ZlqWE4yii1Xu RJPg== 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:references:date:in-reply-to :message-id:user-agent:mime-version; bh=+OxvmTBB8+o117GHLPuXzP0Xd6JDKHisPtYSehOTr9Q=; b=trOB5pwHduAR5kZjX5Nb+KRUBDZJ4s3om2WxYiRY22khoIHrYRQDiTh7xSBFyaHxVQ WpYGFxsQIKiDZ3Fyu4baawn51zokEiPGW3AIXEra/GQ9v00zqKAgXZeRmxZSPaVAFvU+ +GKfi5V0xNfvp0HVktB7COwU3gNJfL66dQLBBZNTWgY6kQ2AhcwMdIHFWSZ9Lsv/Gvmm K56JhQdDVKB7+Iqtwu8s8OevKPSHWNXfkZrN8IsG6IsCOeKa7ym79lJ5ykIeMloH7ivX DA0sCuvsLgsCdsVqbHhzmGQm8WESBRcVIDKpFTXQ8nZwj4OAkVEepRPUU0cpr89o68Ve MCLg== X-Gm-Message-State: APjAAAVk1pF1VvZ6u6wmat+o0dV5r27LWAxiulBq8IWdnwAUI8oGT6TA itkhzKaJf6grj/TBkqt4ZfqokQhy X-Google-Smtp-Source: APXvYqxr1DEG8LrcwS+omwDfNXlG6YToLORuTlXC0oaPE8+dI0ll3aIBxwO6O4vHUGTGX9HqsTBK4Q== X-Received: by 2002:aa7:82cb:: with SMTP id f11mr66676617pfn.0.1555191688894; Sat, 13 Apr 2019 14:41:28 -0700 (PDT) Original-Received: from lylat ([2604:3d09:e37f:1500:1a72:4878:e793:7302]) by smtp.gmail.com with ESMTPSA id 19sm51384819pga.88.2019.04.13.14.41.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 13 Apr 2019 14:41:27 -0700 (PDT) In-Reply-To: (Keith David Bershatsky's message of "Sat, 13 Apr 2019 11:07:55 -0700") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::433 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:235411 Archived-At: Keith David Bershatsky writes: > Thank you, Alex, for helping to diagnose the issue of excessive garbage > collection. I observe the issue when building Emacs on an OSX machine using the > --with-ns flag. The issue may also occur on the w32 and X11 builds of Emacs, but > it is not noticeable to my naked eye. The NS build, on the other hand, permits > me to see an appreciable pause for garbage collection every few keystrokes. The > garbage collection tests with *_consed that I performed today were on the NS > port of Emacs. If you haven't already, IMO it would do well to perform these tests on w32 or X11 to see if there's any difference even if it's not noticeable. > The usage of Ftruncate in the 04/08/2019 proof concept patch of fake cursors occurs only in w32term.c and xterm.c. Right, I didn't notice that the nsterm.c implementation was missing it. > Perhaps there is a similar mistake I have made that would affect the NS build of > Emacs, or perhaps would affect all of the builds (NS/w32/X11). Just to make sure, how about putting the debug_fg and the associated ASET/make_float calls inside an if (debug_p) in mc_update_text_area? It's probably not it, but it doesn't hurt to cross it off. This might not help much, but I noticed this section: + enum face_id special_char_face_id = + lookup_named_face (w, f, intern ("+-special-character-face"), true); + struct face *special_char_face = FACE_FROM_ID (f, special_char_face_id); + Lisp_Object special_char_fg_color = special_char_face->lface[LFACE_FOREGROUND_INDEX]; + Lisp_Object special_char_fg_vec = mc_color_vector_calc (w, special_char_fg_color); + if (glyph != NULL + && glyph->u.ch == 95 + && cursor_type == HBAR_CURSOR) + foreground = special_char_fg_vec; It would be better to place everything within the conditional here, since mc_color_vector_calc calls make_float: + if (glyph != NULL + && glyph->u.ch == 95 + && cursor_type == HBAR_CURSOR) + { + enum face_id special_char_face_id = + lookup_named_face (w, f, intern ("+-special-character-face"), true); + struct face *special_char_face = FACE_FROM_ID (f, special_char_face_id); + Lisp_Object special_char_fg_color = special_char_face->lface[LFACE_FOREGROUND_INDEX]; + Lisp_Object special_char_fg_vec = mc_color_vector_calc (w, special_char_fg_color); + foreground = special_char_fg_vec; + } P.S. I also noticed SSDATA (build_string ("string")) that I believe should just be "string" (with the return type being const char *). Also, the CHARACTERP (make_fixnum (arg)) could be: 0 <= arg && arg <= MAX_CHAR which is how other code in Emacs appears to check if a C int is a character.