From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id iMfGGpOftGNaxw4AWB0awg (envelope-from ) for ; Tue, 03 Jan 2023 16:35:15 -0500 Received: by simark.ca (Postfix, from userid 112) id 62DF01E222; Tue, 3 Jan 2023 16:35:15 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=nFsPxYPM; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id BFDF71E0D3 for ; Tue, 3 Jan 2023 16:35:14 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 706993858D3C for ; Tue, 3 Jan 2023 21:35:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 706993858D3C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1672781714; bh=j/6LjHfC68oyNtfllOezViYP2ewI7TTYOlgY7/Bm0oI=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=nFsPxYPMY4lmK6Y0hq5IKM3h5mOI62vnaVmV2A0Ta5UubjwfWVIkV1JPFw8nfiZAo boLeFcrI51AW5DSISQ6EhJFCr72ViSrKDwV7djoJZA3aJbcP9bPgX4Y16OOJ+KCZcD i9RF06ODe8tXDp/edKTp/DI0Sq87mjIoSXIVNMOE= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id C22F73858D1E for ; Tue, 3 Jan 2023 21:34:54 +0000 (GMT) Received: from [10.0.0.11] (unknown [217.28.27.60]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id AC2B11E0D3; Tue, 3 Jan 2023 16:34:53 -0500 (EST) Message-ID: <46d7fd4b-d5f0-0007-3e88-20345e0e0584@simark.ca> Date: Tue, 3 Jan 2023 16:34:53 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: Two observations using GDB 13 snapshot Content-Language: en-US To: Christian Biesinger , Eli Zaretskii Cc: tom@tromey.com, gdb-patches@sourceware.org, luis.machado@arm.com References: <83h6xugc5v.fsf@gnu.org> <58b64bf8-90b6-d080-c060-d03761501199@arm.com> <83k02neezy.fsf@gnu.org> <835ye7e9jw.fsf@gnu.org> <87h6xrks77.fsf@tromey.com> <83mt7idacj.fsf@gnu.org> <87fsd4elb2.fsf@tromey.com> <83o7rs4qmg.fsf@gnu.org> <87cz84dasj.fsf@tromey.com> <835ydw20bw.fsf@gnu.org> <87wn6bbi5m.fsf@tromey.com> <83sfgz8m9i.fsf@gnu.org> <87o7rnb0ya.fsf@tromey.com> <83a6368chf.fsf@gnu.org> <87k02aaxc8.fsf@tromey.com> <83wn6a6n21.fsf@gnu.org> <587b899f-0f93-530a-7313-d4e1f9e501b9@simark.ca> <835ydt6jzw.fsf@gnu.org> <83wn63z81w.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 1/3/23 15:34, Christian Biesinger via Gdb-patches wrote: > On Tue, Jan 3, 2023 at 3:17 PM Eli Zaretskii wrote: >> >>> From: Christian Biesinger >>> Date: Tue, 3 Jan 2023 14:44:56 -0500 >>> Cc: Simon Marchi , tom@tromey.com, gdb-patches@sourceware.org, >>> luis.machado@arm.com >>> >>>>> https://stackoverflow.com/questions/36686381/windows-c-runtime-toupper-slow-when-locale-set >>>>> https://bugs.php.net/bug.php?id=45265 >>>> >>>> I couldn't see any numbers there about the performance of tolower >>>> itself, i.e. how many ms per call does it take on Windows vs glibc. >>>> But if someone can show a patch to try to eliminate the calls to >>>> tolower, I can try and see if it affects the processing time in this >>>> scenario. >>> >>> Seems like that could be tested by running gdb with LANG=C and/or >>> commenting out the setlocale calls in gdb/main.c? >> >> Setting LANG in the environment doesn't have any effect on Windows, >> since the Windows version of setlocale is insensitive to LANG and LC_* >> environment variables. > > Well you could still try commenting out the setlocale call. > > In terms of the code, may be worth trying TOLOWER from > include/safe-ctype.h instead of tolower() The tolower call is inside strcasecmp, we don't call tolower directly: #0 0x77c348d5 in msvcrt!__crtLCMapStringA () from C:\WINDOWS\system32\msvcrt.dll #1 0x77c348cd in msvcrt!__crtLCMapStringA () from C:\WINDOWS\system32\msvcrt.dll #2 0x77c30045 in wmktemp () from C:\WINDOWS\system32\msvcrt.dll #3 0x77c1c992 in tolower () from C:\WINDOWS\system32\msvcrt.dll #4 0x77c462a1 in stricmp () from C:\WINDOWS\system32\msvcrt.dll #5 0x005107d3 in strcasecmp (__s2=, __s1=) at d:/usr/include/strings.h:92 #6 cooked_index_entry::operator< (this=, other=...) at ./dwarf2/cooked-index.h:150 It would be interesting to change that strcasecmp call to strcmp, just to see if it makes an impact on the performance. Whether or not that would be correct is another thing, but it would help see if that strcasecmp / tolower call is really at fault here. Simon