Why doesn't Info `T' cache node tree for current file?

Why doesn't Info `T' cache node tree for current file?

[Drew Adams]

Info-toc seems to build the TOC from scratch (via Info-build-toc) each time it
is called. Just wondering why.

I understand that the TOC built depends on the current Info file, but I'm
wondering why the node list (tree) for a given Info file isn't kept around, to
avoid rebuilding it each time a user hits `T'.

Just trying to understand the code a bit better - not necessarily suggesting any
change is needed.

Re: Why doesn't Info `T' cache node tree for current file?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 10 Jun 2008 09:59:56 -0700
> 
> I understand that the TOC built depends on the current Info file, but I'm
> wondering why the node list (tree) for a given Info file isn't kept around, to
> avoid rebuilding it each time a user hits `T'.

AFAIK, Info doesn't maintain the node structure (it doesn't need to be
a tree, btw, it could be a graph) in memory at all.  It doesn't need
to, except for Info-toc.  So if you are suggesting that the results of
Info-toc should be stashed away waiting for the user to invoke
Info-toc again for the same Info file, then maybe we should do it;
otherwise, generating the node graph just so TOC would be created
faster is IMO not a good idea.

Btw, I can understand why whoever wrote Info-toc didn't save the
resulting buffer: Info always throws away the (sub-)file when it
switches to another, and *toc* is treated the same way.  So it fits
better into the overall code structure, whereby a file is visited (in
this case, generated out of thin air), displayed, then its buffer
discarded.

RE: Why doesn't Info `T' cache node tree for current file?

[Drew Adams]

> > I understand that the TOC built depends on the current Info 
> > file, but I'm wondering why the node list (tree) for a given
> > Info file isn't kept around, to avoid rebuilding it each
> > time a user hits `T'.
> 
> AFAIK, Info doesn't maintain the node structure (it doesn't need to be
> a tree, btw, it could be a graph) in memory at all.  It doesn't need
> to, except for Info-toc.  So if you are suggesting that the results of
> Info-toc should be stashed away waiting for the user to invoke
> Info-toc again for the same Info file, then maybe we should do it;

Yes, that's what I was thinking of.
But I was just wondering why it isn't done. "Could", not  "should".

> otherwise, generating the node graph just so TOC would be created
> faster is IMO not a good idea.

Right. No, I was thinking of the former - to avoid rebuilding.

> Btw, I can understand why whoever wrote Info-toc didn't save the
> resulting buffer: Info always throws away the (sub-)file when it
> switches to another, and *toc* is treated the same way.  So it fits
> better into the overall code structure, whereby a file is visited (in
> this case, generated out of thin air), displayed, then its buffer
> discarded.

I was thinking more of saving the node list (result of Info-build-toc) than the
buffer. It could be discarded when you visit another Info file, instead of
immediately.

Actually, `T' seems to create the TOC buffer quite quickly. I'm a bit surprised,
when I look at the code. It seems like it would not be so quick.

Re: Why doesn't Info `T' cache node tree for current file?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <emacs-devel@gnu.org>
> Date: Tue, 10 Jun 2008 11:09:20 -0700
> 
> > AFAIK, Info doesn't maintain the node structure (it doesn't need to be
> > a tree, btw, it could be a graph) in memory at all.  It doesn't need
> > to, except for Info-toc.  So if you are suggesting that the results of
> > Info-toc should be stashed away waiting for the user to invoke
> > Info-toc again for the same Info file, then maybe we should do it;
> 
> Yes, that's what I was thinking of.
> But I was just wondering why it isn't done.

Simple: because it isn't needed.  All Info needs to move from a node
is 3 pointers (next, prev, and up), and these are written on the
header line of each node.  So there's no need to build any structure
in memory at all, the information is always at Info's fingertips.

> Actually, `T' seems to create the TOC buffer quite quickly.

One more reason not to bother saving it.

> I'm a bit surprised, when I look at the code. It seems like it would
> not be so quick.

It gets help from the detailed node listing in the Top node.

RE: Why doesn't Info `T' cache node tree for current file?

[Drew Adams]

> > > AFAIK, Info doesn't maintain the node structure (it 
> > > doesn't need to be a tree, btw, it could be a graph)
> > > in memory at all.  It doesn't need to, except for
> > > Info-toc.  So if you are suggesting that the results of
> > > Info-toc should be stashed away waiting for the user to invoke
> > > Info-toc again for the same Info file, then maybe we should do it;
> > 
> > Yes, that's what I was thinking of.
> > But I was just wondering why it isn't done.
> 
> Simple: because it isn't needed.  All Info needs to move from a node
> is 3 pointers (next, prev, and up), and these are written on the
> header line of each node.  So there's no need to build any structure
> in memory at all, the information is always at Info's fingertips.

Wondering why it isn't done... for the same reason you agreed "maybe we should
do it": to save rebuilding (efficiency).

I know it's not needed for node navigation.

And, as I said, I can see that it is not in fact needed for efficiency - which
was a bit surprising to me.

> > Actually, `T' seems to create the TOC buffer quite quickly.
> > I'm a bit surprised, when I look at the code. It seems like it would
> > not be so quick.
> 
> It gets help from the detailed node listing in the Top node.

Yes, I saw that. It's still a bit surprising.

Anyway, no _need_ to do anything. My thought was that if someone uses `T', s?he
is likely to do so again, and likely with the same file. Since we have gone to
the trouble of building the node tree (graph), why not save it for possible
reuse? That's all. It was after sending that thought that I experimented some
more and saw that building the tree is quicker than I expected - and quick
enough.

Re: Why doesn't Info `T' cache node tree for current file?

[Juri Linkov]

> Anyway, no _need_ to do anything. My thought was that if someone uses `T', s?he
> is likely to do so again, and likely with the same file. Since we have gone to
> the trouble of building the node tree (graph), why not save it for possible
> reuse? That's all.

It is not very quick, since the code has to reread all Info subfiles
(its slowest part).  When the delay after typing `T' is more than 1 sec,
this is unbearable for many users.  So we could cache the TOC buffer per
Info file, if this costs us nothing.  I see one problem: how to refresh
the cached TOC buffer when the Info file changes - the usual key `g'
for buffer refreshing is already allocated to `Info-goto-node'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Why doesn't Info `T' cache node tree for current file?

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
> I see one problem: how to refresh
> the cached TOC buffer when the Info file changes - the usual key `g'
> for buffer refreshing is already allocated to `Info-goto-node'.

If it's an issue, it should be done automatically, not by user action.
It seems simple enough to cache a timestamp and do a compare when the
user types "T" ...

-Miles

-- 
Immortality, n.  A toy which people cry for, And on their knees apply for,
      Dispute, contend and lie for, And if allowed Would be right proud
      Eternally to die for.

Re: Why doesn't Info `T' cache node tree for current file?

[Stefan Monnier]

>> Anyway, no _need_ to do anything. My thought was that if someone uses
>> `T', s?he is likely to do so again, and likely with the same
>> file. Since we have gone to the trouble of building the node tree
>> (graph), why not save it for possible reuse? That's all.

> It is not very quick, since the code has to reread all Info subfiles
> (its slowest part).  When the delay after typing `T' is more than 1 sec,
> this is unbearable for many users.

I haven't heard any complaint about it, so it looks like those delays
rarely if ever occur.  And I believe machines are getting faster more
quickly than manuals are getting larger, so I don't expect reports to
become much more frequent in the future.

OTOH, such caching might be necessary for Drew's breadcrumbs (a small
delay is fine for `T' but is problematic if it occurs at every page).

> So we could cache the TOC buffer per Info file, if this costs us
> nothing.  I see one problem: how to refresh the cached TOC buffer when
> the Info file changes - the usual key `g' for buffer refreshing is
> already allocated to `Info-goto-node'.

The refresh should be 100% automatic by recording the timestamps of
the files.


        Stefan

RE: Why doesn't Info `T' cache node tree for current file?

[Drew Adams]

> > My thought was that if someone uses `T', s?he is likely
> > to do so again, and likely with the same file. Since we
> > have gone to the trouble of building the node tree
> > (graph), why not save it for possible reuse? That's all.
> 
> It is not very quick, since the code has to reread all Info subfiles
> (its slowest part).

That was my thinking - it really does seem to do quite a lot of work.

On the other hand, at least with the manuals I use (Emacs and Elisp), it seems
pretty snappy to me. Do you really see a performance problem, or is this just
hypothetical?

> When the delay after typing `T' is more than 1 sec, this is
> unbearable for many users.

Whoa! That certainly would be unbearable. I don't see anything like that. It
seems instantaneous, to me (which surprises me, since it does all of the
`Info-goto-node' stuff).

Can you give a recipe (e.g. which manual)?

> So we could cache the TOC buffer per Info file, if this costs
> us nothing.

Either the TOC buffer or the node list, depending on performance needs etc.

> I see one problem: how to refresh the cached TOC buffer when
> the Info file changes

Do you mean when you go to a different manual (different file), or do you mean
when someone changes the file on disk?

I think we can ignore the latter (no?).

And I think the former would be easy to take care of. As I see it (and I think I
said this), the file name would be associated with the cached node list (or
buffer). When the current file is different and you hit `T', a new TOC is built.


Should we keep caches already built for previously visted files or just toss
them? Could be a user option - users with lots of resources might opt for
multiple caches; others not.

> - the usual key `g' for buffer refreshing is already
> allocated to `Info-goto-node'.

No - it should be automatic - see above.

RE: Why doesn't Info `T' cache node tree for current file?

[Drew Adams]

> I haven't heard any complaint about it, so it looks like those delays
> rarely if ever occur.  And I believe machines are getting faster more
> quickly than manuals are getting larger, so I don't expect reports to
> become much more frequent in the future.
> 
> OTOH, such caching might be necessary for Drew's breadcrumbs (a small
> delay is fine for `T' but is problematic if it occurs at every page).

I don't see any performance problem. Can you refer to a specific scenario, so we
can talk concretely if there is really a performance problem?

> > So we could cache the TOC buffer per Info file, if this costs us
> > nothing.  I see one problem: how to refresh the cached TOC 
> buffer when
> > the Info file changes - the usual key `g' for buffer refreshing is
> > already allocated to `Info-goto-node'.
> 
> The refresh should be 100% automatic by recording the timestamps of
> the files.

See my replies to others. What kind of file changes are we talking about: (a)
change of the file on disk or just (b) change by the user to visit a different
file?

Why would we worry about (a)?
For (b), why wouldn't we just associate the file name with the cache?

RE: Why doesn't Info `T' cache node tree for current file?

[Drew Adams]

> > I see one problem: how to refresh
> > the cached TOC buffer when the Info file changes - the usual key `g'
> > for buffer refreshing is already allocated to `Info-goto-node'.
> 
> If it's an issue, it should be done automatically, not by user action.

Agreed.

> It seems simple enough to cache a timestamp and do a compare when the
> user types "T" ...

Why a timestamp? What kind of "file changes" are we talking about? (See my
replies to others about this.)

Re: Why doesn't Info `T' cache node tree for current file?

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: "Eli Zaretskii" <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Wed, 11 Jun 2008 03:02:15 +0300
> 
> I see one problem: how to refresh the cached TOC buffer when the
> Info file changes

I can refresh it the first time the user invokes Info-toc and you
discover that the Info file is different from what it was last time
you created the TOC.

RE: Why doesn't Info `T' cache node tree for current file?

[Drew Adams]

> > I see one problem: how to refresh the cached TOC buffer when the
> > Info file changes
> 
> I can refresh it the first time the user invokes Info-toc and you
> discover that the Info file is different from what it was last time
> you created the TOC.

Yes, that's the way I see it. The file is associated with the TOC.

If, when the user hits `T', the current manual (file) is different from the one
associated with the cached TOC, then you build a new TOC.

The question is whether it's worth saving both caches. Memory/time trade-off.

Re: Why doesn't Info `T' cache node tree for current file?

[Juri Linkov]

>> It is not very quick, since the code has to reread all Info subfiles
>> (its slowest part).
>
> That was my thinking - it really does seem to do quite a lot of work.
>
> On the other hand, at least with the manuals I use (Emacs and Elisp), it seems
> pretty snappy to me. Do you really see a performance problem, or is this just
> hypothetical?

If you have a fast machine, this doesn't mean everyone has the same.
Try on at least 300MHz proc to see how quick it is.

>> I see one problem: how to refresh the cached TOC buffer when
>> the Info file changes
>
> Do you mean when you go to a different manual (different file), or do you mean
> when someone changes the file on disk?
>
> I think we can ignore the latter (no?).

The same Info file doesn't change too often, but there are situations when
for instance, the user writes a new Info manual, and in the process of
writing uses the TOC as an overview of the manual (i.e. iterations like
add a new node, revisit the TOC, reorganize its structure, and so on).

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Why doesn't Info `T' cache node tree for current file?

[Drew Adams]

> >> It is not very quick, since the code has to reread all 
> >> Info subfiles (its slowest part).
> >
> > That was my thinking - it really does seem to do quite a 
> > lot of work.
> >
> > On the other hand, at least with the manuals I use (Emacs 
> > and Elisp), it seems pretty snappy to me. Do you really see
> > a performance problem, or is this just hypothetical?
> 
> If you have a fast machine, this doesn't mean everyone has the same.
> Try on at least 300MHz proc to see how quick it is.

I won't be trying a different machine, but perhaps someone else can.

Can you point to a particular manual for which this is unacceptably slow on a
slow machine? IOW, can you point to a concrete case that people with slow
machines can check?

> >> I see one problem: how to refresh the cached TOC buffer when
> >> the Info file changes
> >
> > Do you mean when you go to a different manual (different 
> > file), or do you mean when someone changes the file on disk?
> >
> > I think we can ignore the latter (no?).
> 
> The same Info file doesn't change too often, but there are 
> situations when for instance, the user writes a new Info
> manual, and in the process of writing uses the TOC as an
> overview of the manual (i.e. iterations like
> add a new node, revisit the TOC, reorganize its structure, and so on).

Ah, I see - the use case is for Info manual writers.

That is important, but it is still a minority use case. Perhaps those people
could live with restarting Emacs. Or perhaps they could just delete the cache
manually so that it gets rebuilt. IOW, do you really think this is an important
enough use case to worry about?

Re: Why doesn't Info `T' cache node tree for current file?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: "'Eli Zaretskii'" <eliz@gnu.org>, <emacs-devel@gnu.org>
> Date: Wed, 11 Jun 2008 06:46:39 -0700
> 
> > The same Info file doesn't change too often, but there are 
> > situations when for instance, the user writes a new Info
> > manual, and in the process of writing uses the TOC as an
> > overview of the manual (i.e. iterations like
> > add a new node, revisit the TOC, reorganize its structure, and so on).
> 
> Ah, I see - the use case is for Info manual writers.

Not necessarily.  The situation I bump into much more frequently is
when I update from CVS, then say "make info" with the Info manual
already loaded into one of my (many) Info buffers.

However, I don't think this is important enough to justify
over-optimization.  `T' is already a rarely used command (I bet many
users don't even know it exists); adding an Info file that is modified
under our feet makes it _extremely_ rare.