From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1672781694; bh=9e6h4l24AOIR9Ps0JT3bZCjb5Z1yxxKkdNfwBUfX27Y=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=JsJWPKcmKw+2zWxITxK17i0jkl3isCp1OWdxY7QL1I0m6z6nAsBK2f7/O/qDCm0zV r1oiD2H5uXTcJixKQjtFiiLw1FRXSPQOA2LZWS0mV5NRrqgJf4D0N8PLNBgNjKLO9W ckAy3czFHeMK5BGoUm/bF92ZWPNym+rykoMFN6TQ= 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> From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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