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

[Eli Zaretskii]

> Date: Fri, 02 Jan 2015 18:05:40 +0200
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden
> 
> > Date: Fri, 2 Jan 2015 15:47:50 +0000
> > From: Gavin Smith <address@hidden>
> > Cc: Texinfo <address@hidden>
> > 
> > On Fri, Jan 2, 2015 at 11:26 AM, Eli Zaretskii <address@hidden> wrote:
> > > However, I see an annoying delay when going to a different node.  For
> > > example, in the Emacs Lisp manual, go to the "Index" node, move to the
> > > end of the index, type RET on one of the last entries, then type 'l'
> > > to go back.  Bot going to Index and going back causes a visible delay,
> > > which is about 1.5 sec here (this is a Core-i7 box).
> > 
> > I couldn't reproduce this. There is a slight delay for me when loading
> > the Index node for the first time, but not when going back. I would
> > guess it is because it is the Index node is a long node and it is
> > doing something when displaying it that takes a long time (like
> > calculating the positions of the starts of lines).
> 
> I don't think so: the Info viewer from Texinfo 4.13 doesn't have this
> problem, I tried with the same files.
> 
> > I can't see how this would be related to CR removal. Do other nodes
> > in the file also this problem?
> 
> OK, I will take a closer look.

The bottle-neck is clearly process_node_text, it takes more than 1 sec
when the node is "Index" in the ELisp manual.

I timed the loop in process_node_text, and it takes about 0.22 msec
per line on the average, and there are 5700 lines in that node.

I tried to find the culprit in that loop, but it's hard to time such
small intervals reliably.  My gut feeling is that the call to
printed_representation is the reason: we call that function once for
each character on the line.  But I cannot prove that, and I cannot
explain why you don't see the same delay.  Perhaps the reason is that
some functions called by printed_representation, which in my build are
supplied by gnulib, are much faster in glibc.  This is based on the
following profile I get from gprof:

  Each sample counts as 0.01 seconds.
    %   cumulative   self              self     total
   time   seconds   seconds    calls  Ts/call  Ts/call  name
   50.00      0.02     0.02                             locale_charset
   25.00      0.03     0.01                             wcwidth
   12.50      0.04     0.01                             
add_file_directory_to_path
   12.50      0.04     0.01                             main
    0.00      0.04     0.00   415064     0.00     0.00  printed_representation
    0.00      0.04     0.00   229065     0.00     0.00  reset_conversion
    0.00      0.04     0.00    61093     0.00     0.00  text_buffer_alloc
    0.00      0.04     0.00    51681     0.00     0.00  text_buffer_iconv
    0.00      0.04     0.00    51681     0.00     0.00  text_buffer_space_left
    0.00      0.04     0.00    31362     0.00     0.00  skip_whitespace
    0.00      0.04     0.00    19793     0.00     0.00  read_quoted_string

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.