From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3 Date: Tue, 31 Mar 2020 16:07:50 +0300 Message-ID: <834ku43c61.fsf@gnu.org> References: <86tv2h2vww.fsf@gmail.com> <20200322123818.GB32470@ACM> <87eetk5swm.fsf@gnu.org> <20200326193128.GC14092@ACM> <86d08y4zsx.fsf@gmail.com> <83sghs7qdz.fsf@gnu.org> <83h7y63sjj.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="31588"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, rrandresf@gmail.com, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 31 15:08:20 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 1jJGct-00088c-S2 for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Mar 2020 15:08:19 +0200 Original-Received: from localhost ([::1]:37684 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJGcs-0004uF-TU for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Mar 2020 09:08:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39859) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJGcM-0004V0-LR for emacs-devel@gnu.org; Tue, 31 Mar 2020 09:07:47 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37625) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jJGcM-0006s3-68; Tue, 31 Mar 2020 09:07:46 -0400 Original-Received: from [176.228.60.248] (port=4721 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jJGcE-0002r5-Ly; Tue, 31 Mar 2020 09:07:39 -0400 In-Reply-To: (message from Richard Stallman on Mon, 30 Mar 2020 22:28:10 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:246088 Archived-At: > From: Richard Stallman > Cc: acm@muc.de, rrandresf@gmail.com, emacs-devel@gnu.org > Date: Mon, 30 Mar 2020 22:28:10 -0400 > > > For new features that can be disabled, that is mostly the case > > anyway. But most new features we add don't have such knobs, usually > > because we don't envision anyone to want them. > > My point is, if a feature causes significant slowdown, in general usage, > that in itself is a reason to give it a knob. When we know a new feature causes significant slowdown, we either fix it, or provide a way to disable or work around it. The problem is, we don't always know there's slowdown, as it frequently happens only in specific rare use cases. (John said some time ago we should have a benchmarking test suite, but I don't think anyone's working on it.) Also, several slowdowns each of which is minor can together cause a significant slowdown, and in that case it is even harder to detect and fix that.