From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65757 invoked by alias); 21 Jun 2019 17:35:29 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 65745 invoked by uid 89); 21 Jun 2019 17:35:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=stress, palves, HX-Languages-Length:1800, yours X-HELO: mail-wm1-f66.google.com Received: from mail-wm1-f66.google.com (HELO mail-wm1-f66.google.com) (209.85.128.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 21 Jun 2019 17:35:28 +0000 Received: by mail-wm1-f66.google.com with SMTP id s3so7042726wms.2 for ; Fri, 21 Jun 2019 10:35:27 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id z126sm3944831wmb.32.2019.06.21.10.35.25 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jun 2019 10:35:25 -0700 (PDT) Subject: Re: [PATCH v2] Fix slow and non-deterministic behavior of isspace() and tolower() To: Shawn Landden , gdb-patches@sourceware.org References: <20190609151704.16061-1-shawn@git.icu> <20190610213017.2021-1-shawn@git.icu> Cc: jhb@freebsd.org, eliz@gnu.org From: Pedro Alves Message-ID: <7afb14c1-ef9e-a0d3-3b46-77793f5a8251@redhat.com> Date: Fri, 21 Jun 2019 17:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20190610213017.2021-1-shawn@git.icu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-06/txt/msg00439.txt.bz2 Hi, On 6/10/19 10:30 PM, Shawn Landden wrote: > I was getting 8% and 6% cpu usage in tolower() and isspace(), > respectively, waiting for a breakpoint on ppc64el. > > Also, gdb doesn't want non-deterministic behavior here. > > v2: do not clash with C99 names When I was working on the C++ wildmatching support a couple years ago, I had some testcases that would stress name parsing that I was running under perf, and I also noticed these functions higher up on the profile. I wrote a few patches back then: https://github.com/palves/gdb/commits/palves/ada-decode-speedups And this one has the same idea as yours: https://github.com/palves/gdb/commit/f701531b79380356134d53db97adb6f467f9d784 So, I agree that this makes sense. I also agree that we don't want to depend on the current locale when parsing symbol names. In my version I was naming the functions gdb_xxx while in your version you're using xxx_inline. gdb_xxx naming is more common as a gdb version of some standard function, so I would prefer that. But, meanwhile, last year I merged this patch: which touches a somewhat subject. That patch uses the existing libiberty uppercase TOLOWER, ISXDIGIT, etc. macros, which are inline and locale independent by design. See include/safe-ctype.h. Can we use those instead of adding new functions? I don't recall if I benchmarked ISSPACE vs the gdb_isspace in that optimization patch on my github, but I think I just didn't remember ISSPACE back then. Least but not least, the patch as is is not following the GNU/GDB coding format conventions. Take a look here: https://sourceware.org/gdb/wiki/ContributionChecklist Thanks, Pedro Alves