bugGNU Octave - Bugs: bug #49193, help slow because of makeinfo

 
 

bug #49193: help slow because of makeinfo

Submitter:  None
Submitted:  Mon 26 Sep 2016 08:07:46 PM UTC
   
 
Category:  Performance Severity:  1 - Wish
Priority:  3 - Low Item Group:  Regression
Status:  Wont Fix Assigned to:  None
Originator Name:  Michael Leitner Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * dev
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 29 Feb 2024 12:57:13 PM UTC, comment #7: 

What version of makeinfo do we include with the windows crossbuilds now?  I also see no noticeable delay on windows or ubuntu vm. Its been long enough without any activity to change the doc system, I'm going to close this as a won't fix.  Easy enough to reopen or generate a new report if there's interest later.

Nicholas Jankowski <nrjank>
Group Member
Thu 29 Feb 2024 08:01:30 AM UTC, comment #6: 

No lag now. No more bug.

Anonymous
Tue 27 Sep 2016 07:21:30 AM UTC, comment #5: 

I'm the one from the original report:
My timing was done on my home PC, which is an Intel Atom from 2010, which from experience I know to be easily a factor of 5 slower than my i5 at work. Sadly/fortunately, at work I have makeinfo 4.13, which formats the help text in 0.008 s.

Yes, already when I wrote the bug report, I compared the 30 minutes invested by me to possible savings. And I think 10 hours to be a rather optimistic estimate. And yes, I know that this would have to also track when user-written functions are modified to reformat the help text the first time it is requested, but the harder part of such a mechanism seems to be already in place (ignore_function_time_stamp...).

But to me it seems that historically the largest part of free software coding stemmed from personal irritations, and if J. Random Hacker each time would have drawn up a business plan whether it is worth to set out implementing anything, the tens of thousands of programs nobody but himself ever used would not have been written (no problem there), but also not the hundreds that enable us today to use a computer as a tool that feels like an extension of the fingertips. So all that I intended with my post was (first) to document a dirty solution to anyone that stumbles over the problem and does a quick search, and (second) that perhaps somebody indeed thinks "Ah, now that I read it, this is what has been irritating me all along!", and starts to work on a better solution.

So yes, this is only wishlist, and if I got the help text in 0.2 s, I probably would not have noticed the lag, let alone reported a bug. But seen from the other side, I think that the texinfo people only reimplemented makeinfo in perl, thereby sacrificing speed, because they assumed that the output gets cached in the info files.

Anonymous
Mon 26 Sep 2016 11:25:46 PM UTC, comment #4: 

makeinfo-6.0.0, so maybe that's why it's better for me.

Rik <rik5>
Group administrator
Mon 26 Sep 2016 11:06:14 PM UTC, comment #3: 

Rik - are you using makeinfo 6.x? I also see times of about 150-200 ms on my system with makeinfo 6.3. I do have 4.13 hanging around for comparison, but I don't have a working copy of 5.x to compare against to see how much slower it was. Anecdotally I remember 6.x as being noticeably faster than 5.x when the new release appeared, FWIW.

I also don't think it's worth the developer time personally, but someone may feel inclined to work on something like this. Could be transplanted to the Projects wiki page.

Mike Miller <mtmiller>
Group Member
Mon 26 Sep 2016 10:57:59 PM UTC, comment #2: 

There are no quick solutions here.  This has been a known irritant since makeinfo switched to Perl.

In general, the opinion has been that documentation ('help xxx') and errors ('print_usage') are both slow paths that operate on human time scales.  In this case, hundreds of milliseconds is an acceptable delay.  If this were somehow in the core of frequently called loops, like BLAS operations, we would make a different optimization decision.

At least on my machine, the first example isn't nearly so slow as your machine even with Perl.


octave:1> [text, format] = get_help_text ("lastwarn");
octave:2> tic; __makeinfo__ (text, "plain text");toc
Elapsed time is 0.19404 seconds.


Mike suggested that there is possible work that could be done on a documentation cache for "plain text".  That is true, but it might not be worth the programmer time.  If I assume the feature takes 10 hours to architect, implement, and debug, and I also assume that you are able to shave 1 second off the execution time, then for an individual they would not recoup the time spent on implementing the feature until they had called help 36,000 times.  That's pretty hard to justify.  Of course, you would be helping other people enjoy Octave more so one could make an altruistic argument for implementing the feature, just not a personal one.

Rik <rik5>
Group administrator
Mon 26 Sep 2016 09:37:49 PM UTC, comment #1: 

Please test with makeinfo 6.3 if you are able to. Some notable changes between 5.0 and 6.3 include "Some Perl modules have been rewritten in C to increase speed" and "a bit faster".

That said, yes makeinfo is still perl and it is still noticeably slower than makeinfo 4.13. You are free to use 4.13 on your end, as you have done. Octave won't bundle GNU texinfo with its own distribution, but users and distributors are free to do so if they want.

Something could be done with the doc cache. Such an approach would also have to take into account user .m function files on the load path, which may change or may not exist at any moment.

Another option would be to pursue another doc markup language and processor, but this probably won't be done since Texinfo is the GNU project recommended documentation format, and the same function doc strings are used both for online help as well as for the full manual.

I'll leave this bug open as a wishlist improvement if someone wants to pursue some optimization on how doc strings are loaded and stored in memory.

Mike Miller <mtmiller>
Group Member
Mon 26 Sep 2016 08:07:46 PM UTC, original submission:  

Since version 5.0 of 2013, makeinfo is implemented in perl, as opposed to the previous compiled programs. The texinfo people admit that

"The new program is, unfortunately, noticeably slower at present than the C program was.  We hope all the many improvements make the new version worthwhile for users nevertheless."

but, of course, in the intended workflow it does not matter when you implement some new feature in a few man-hours, document it in ten minutes, and then generating the info text takes a few seconds. In any case, this hits only the developer, not the user.

But at least on my system, this is not how it is with octave: the help function obtains the raw help text by get_help_text() and then passes it through _makeinfo_(), EVERY TIME I display the help for some function. This leads to


> [text, format] = get_help_text ("lastwarn");
> tic; __makeinfo__ (text, "plain text");toc
Elapsed time is 1.41317 seconds.


Luckily, I found a pre-5.0 makeinfo in some dusty installation on my hard disk, dropping it in runs without errors and leads to


> makeinfo_program("/tmp/makeinfo")
> tic; __makeinfo__ (text, "plain text");toc
Elapsed time is 0.018985 seconds.


Indeed, the whole help invocation takes only unmeasurably longer. On the other hand, 1.4 s unresponsiveness can be somehow irritating, when one is used to immediate responsiveness with today's computers, and when there is no heavy lifting done to justify waiting.

So:
One could bundle old versions of makeinfo with octave and use it as default makeinfo_program (this is what I will do now).
Alternative: Use makeinfo as it is intended, to generate a help text from the source and cache it. Actually, as far as I can see, there is already the doc-cache file, where the help texts are found formatted exactly as they will appear in the command window (it seems that there isn't even a new linebreaking if my terminal deviates from 80 column width). So all that is needed for getting optimal responsiveness is to implement a check in  get_help_text() whether the sought-for function is cached in the doc-cache, and if yes, return it with flag "plain text".

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-02-29 nrjank StatusPostponed Wont Fix
        Open/ClosedOpen Closed
    2016-09-26 mtmiller Severity3 - Normal 1 - Wish
        Priority5 - Normal 3 - Low
        StatusNone Postponed
        Release3.8.2 dev
        Operating SystemGNU/Linux Any

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code