Re: Standalone Info reader cannot read Info files with CR-LF EOLs

[Gavin Smith]

On Sat, Jan 10, 2015 at 3:31 PM, Eli Zaretskii <address@hidden> wrote:
>> Date: Thu, 8 Jan 2015 11:00:40 +0000
>> From: Gavin Smith <address@hidden>
>> Cc: Texinfo <address@hidden>
>>
>> On Sat, Jan 3, 2015 at 3:29 PM, Eli Zaretskii <address@hidden> wrote:
>> > As you see, wcwidth and locale_charset, both from gnulib in my build,
>> > take 75% of the time.
>> >
>> > I thought that perhaps the reason was that your locale is UTF-8, so
>> > Info doesn't need to convert text using libiconv in your locale.  But
>> > removing the UTF-8 encoding tag from the ELisp Info file didn't have
>> > any visible effect on the delay, so that's not it.
>> >
>> > Suggestions for further digging into this are welcome.
>>
>> One way to check would be to comment out the call to wcwidth, and
>> replace with the value "1", and see if it is still slow.
>
> Doing this completely solves the problem.
>
> Moreover, if I replace the line that calls wcwidth:
>
>       *pchars = wcwidth ((*iter).cur.wc);
>
> with what constitutes the body of the gnulib implementation, i.e.:
>
>       *pchars = (*iter).cur.wc ? (iswprint ((*iter).cur.wc) ? 1 : -1) : 0;
>
> I don't see any slowdown, either.
>
> My conclusion is that the reason for the slowdown is the call to
> locale_charset inside gnulib's wcwidth is the culprit, because my
> locale's charset is not UTF-8.
>
> Thanks.

Here's the body of the gnulib wcwidth:

int
wcwidth (wchar_t wc)
#undef wcwidth
{
  /* In UTF-8 locales, use a Unicode aware width function.  */
  const char *encoding = locale_charset ();
  if (STREQ_OPT (encoding, "UTF-8", 'U', 'T', 'F', '-', '8', 0, 0, 0 ,0))
    {
      /* We assume that in a UTF-8 locale, a wide character is the same as a
         Unicode character.  */
      return uc_width (wc, encoding);
    }
  else
    {
      /* Otherwise, fall back to the system's wcwidth function.  */
#if HAVE_WCWIDTH
      return wcwidth (wc);
#else
      return wc == 0 ? 0 : iswprint (wc) ? 1 : -1;
#endif
    }
}

locale_charset is always called every time. It must be slower under a
Windows system. The implementation of locale_charset is in the
localcharset.c file from gnulib, although I haven't looked at it in
detail, and don't know why it would be slow under Windows.