Re: Two observations using GDB 13 snapshot

[Christian Biesinger <cbiesinger@google.com>]

On Tue, Jan 3, 2023 at 4:34 PM Simon Marchi <simark@simark.ca> wrote:
>
>
>
> On 1/3/23 15:34, Christian Biesinger via Gdb-patches wrote:
> > On Tue, Jan 3, 2023 at 3:17 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >>
> >>> From: Christian Biesinger <cbiesinger@google.com>
> >>> Date: Tue, 3 Jan 2023 14:44:56 -0500
> >>> Cc: Simon Marchi <simark@simark.ca>, 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=<optimized out>, __s1=<optimized out>)
>     at d:/usr/include/strings.h:92
> #6  cooked_index_entry::operator< (this=<optimized out>, 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.

It looks like libiberty has a strcasecmp.c that could work, though I
am not sure how one is expected to make sure that libiberty's
strcasecmp is used.

Christian