From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Redisplay slower in Emacs 28 than Emacs 27 Date: Thu, 10 Dec 2020 11:21:42 -0500 Message-ID: References: <87sg8h78s8.fsf@gnus.org> <837dpt8lk5.fsf@gnu.org> <87pn3kjssr.fsf@gnus.org> <83im9c70vu.fsf@gnu.org> <87im9cfeej.fsf@gnus.org> <837dps6xyv.fsf@gnu.org> <87czzkdx57.fsf@gnus.org> <83v9dc5he3.fsf@gnu.org> <87r1o0chk9.fsf@gnus.org> <83tusw5g5o.fsf@gnu.org> <87360gaz7o.fsf@gnus.org> <875z5b9a84.fsf@gnus.org> <83360e6cip.fsf@gnu.org> <83v9da49it.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="27790"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: ghe@sdf.org, 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 Thu Dec 10 17:40:55 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 1knOzv-00078b-4u for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Dec 2020 17:40:55 +0100 Original-Received: from localhost ([::1]:48840 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1knOzu-0006a3-4a for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Dec 2020 11:40:54 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36108) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1knOhT-00018Z-MO for emacs-devel@gnu.org; Thu, 10 Dec 2020 11:21:51 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:56103) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1knOhR-0002Bi-0W; Thu, 10 Dec 2020 11:21:50 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 8F9C180A93; Thu, 10 Dec 2020 11:21:45 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A9FA580ACD; Thu, 10 Dec 2020 11:21:43 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1607617303; bh=KYVVNBI9nr8a3U2hzmJmNT9g3y4t7JLuopAUwBABJA0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=FYuGisVEp3Hzr6f+rjbcRPnAt+4MPwl4LcN6BXqW7Y5blqC/zBMD7w4VO2KtuzxA3 udpk88ous0xzEzQDNsC684IlHvTKc1pLbZs3ahlxu9fYJccotStMW+W0nJR30iwtFQ /LthJ/eiQaajbq604nCGfcWuGDdi4YgJb5lC+bJb+BvcmNM2Pq6Or1njvecaoXuMQs elKhW5iwGw3N1w/xLbKQD0MJU0uC9jbqDvBdJIkpi6HlAyCPKTMFRH/pJUpbVZEQXX SqwvDQvv6yD6j9HJmT+kTI3M4CcSi34rZZJK4+odcLkCeRbDf0Ja8oX+xBEv8l0I1h xccZInCvx+zww== Original-Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6CB9112036E; Thu, 10 Dec 2020 11:21:43 -0500 (EST) In-Reply-To: <83v9da49it.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 10 Dec 2020 05:36:42 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:260659 Archived-At: >> > Btw, any particular reason for the cutoff of 16 bytes to switch to the >> > "large chunk" branch? >> The reason is that I felt it looked good ;-) >> Well, not only: the "large chunk" branch operates 8bytes at a time on >> 64bit systems, so if we use it on a 15B string it will only consult the >> first 8B which I thought wasn't good enough, whereas I felt that >> ignoring the last 7B of a 23B string was acceptable. > Then perhaps we should look for the optimal cutoff by benchmarking > with different values? If someone feels like it, I won't get in the way. Personally, I don't think "optimal" is needed here. BTW, we could also get rid of the "old, slow code" and instead improve the fast code so it doesn't throw away the last <8 bytes. If done right, it would likely also speed up the case of strings shorter than 16 bytes. If we presume that `p` itself is naturally aligned (which I believe should indeed always be the case), then we can safely use a word-sized read at the end (it will read some trailing garbage bytes, but won't risk hitting a memory protection check) and then "mask out" those trailing bytes. But that masking requires endian-dependent code, so I refrained from going down that road. I guess if we could arrange for those trailing bytes to always be the same (e.g. always NUL), then we wouldn't even need to do that masking, but AFAIK while we do make sure there's always a trailing NUL right after the end of our strings, we don't ensure that there are trailing NULs right up to the next multiple of 4-or-8 address. Admittedly, big-endians lost the war and are a disappearing breed nowadays, but they still haven't quite disappeared, sadly [ I was rooting for the big-endians, but given where we're at, I'd rather see big-endians be a thing of the past. ] Stefan