From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97739 invoked by alias); 21 Jun 2019 18:08:41 -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 97731 invoked by uid 89); 21 Jun 2019 18:08:41 -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= X-HELO: mail-wm1-f67.google.com Received: from mail-wm1-f67.google.com (HELO mail-wm1-f67.google.com) (209.85.128.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 21 Jun 2019 18:08:40 +0000 Received: by mail-wm1-f67.google.com with SMTP id x15so7106622wmj.3 for ; Fri, 21 Jun 2019 11:08:39 -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 q21sm3540826wmq.13.2019.06.21.11.08.37 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jun 2019 11:08:37 -0700 (PDT) Subject: Re: [PATCH v2] Fix slow and non-deterministic behavior of isspace() and tolower() To: Shawn Landden References: <20190609151704.16061-1-shawn@git.icu> <20190610213017.2021-1-shawn@git.icu> <7afb14c1-ef9e-a0d3-3b46-77793f5a8251@redhat.com> Cc: gdb-patches@sourceware.org, jhb@freebsd.org, eliz@gnu.org From: Pedro Alves Message-ID: Date: Fri, 21 Jun 2019 18:08: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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-06/txt/msg00442.txt.bz2 On 6/21/19 6:59 PM, Shawn Landden wrote: >> 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 don't care how it gets fixed, and the GNU coding standard (which I write > to for glibc) will take more time than writing this patch. (Or your > well-documented response) Also, while I have a copyright assignment for > glibc, mine for GCC and binutils-gdb is only pending. > > Go ahead and fix this, and give me credit. The interesting thing to do here is >> 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. How were you benchmarking this? Thanks, Pedro Alves