GNOME Bugzilla – Bug 659335
Interface freeze when getting autocompleting for long module.
Last modified: 2011-11-15 05:15:42 UTC
Originally filed by "olethanh" as http://www.reinteract.org/trac/ticket/78 Description when you import a big module such as gtk, the whole interface freeze when trying to autocomplete 03/31/09 21:34:37 changed by otaylor ==================================== So, the details of what are going on here is that when you type: gtk It's trying to popup gtk [gtk] [full docstring for the gtk module] And the docstring for the gtk module takes forever to compute. Which is actually mostly pointless since there is no "completion" here - you've already typed the full module name. (It's less pointless for functions ... argument entry mode is useful even if there is only one completion.) But just avoiding the popup doesn't solve the problem, since it would still occur for modules that are longer than three characters. (Though few modules have as large and expensive to compute docstring as gtk). The real fix is that when completing, the pydoc behavior of adding docs for the module members to the docs for the module is not useful ... you'll see the docs anyways when you get to the next level of completion, and in a more useful fashion. I don't see any way of suppressing this behavior looking at the pydoc sources, so it's probably necessay to reproduce some of the logic of pydoc.TextDoc?.docmodule() 04/02/09 14:54:03 changed by olethanh ===================================== Wouldn't it be possible to do this computation in a thread or in some other which doesn't block the glib mainloop. So it wouldn't prevent the user from continuing to type? 04/03/09 00:36:34 changed by otaylor ==================================== Using a thread or breaking the operation up into small bits that could be done in idle time was my initial thought. But since what is taking so long is entirely pointless - nobody wants a tooltip with all 1200+ members of the gtk module every time they type 'gtk' - the first step is to just avoid doing that operation. If there continue to be problems in other situations then we can take further steps.
Created attachment 201261 [details] [review] Use a custom documentation formatter Looking through what the pydoc.TextDoc formatter was doing, I noticed that it was including full docs for each class in the module docs. This is obviously useful if you're printing them out, but for interactive use, this is pretty useless. This patch provides a new formatter, inheriting from the pydoc one, that only includes class names and docstrings in the module docs. Class docs requested on their own are unaffected. This improves performance significantly in my testing. Previously, I had a 10 second freeze to format the gtk docs; with this patch, it's down to 1 second. Additional improvement along these lines may be possible in simplifying the docs for functions and other objects in modules, but it looks like this was the low-hanging fruit. There may be copyright issues with this patch: Most of TextDocShort.docclass() was cribbed from the pydoc sources, which do not have clear copyright or licensing statements. I'm assuming that, as part of the standard library, pydoc is distributed under the PSF licence, which I think means we can use it in the BSD-licensed Reinteract. Someone who knows better should make sure.
Any thoughts about applying a strict non-recurse policy to docs - that is, when displaying the docs for a module, show only the NAME/FILE/DESCRIPTION and not the PACKAGE CONTENTS/SUBMODULES/CLASSES, for displaying the docs for a class, show only the class docs and not not the method docs.. I suppose it's possible that the methods of a class or the members of a module might be useful to tell you if it's what you want, but in general it seems like if I want to find some class in GTK+ I'll type gtk. and go through the list, and not gtk<f2> and page-down. I don't have any problems including PSF code, and if it's just a few lines, I think it can just be noted in place and doesn't need to go in Reinteract's overall license statement - just add a note: # This code derived from pydoc.py in the Python distribution # Copyright Python Software Foundation, 2011, licensed under the # terms of the Python Software Foundation License, version 2 doesn't have to be completely 100% accurate - just close.
Created attachment 201416 [details] [review] Use a custom documentation formatter Add a copyright notice about the pydoc code.
Created attachment 201417 [details] [review] Use a custom documentation formatter for shorter module docs I think it's fine to cut out some of the information of the module docs. The popups are really useful for remembering how to use a particular function or class. I don't see them as a good way to learn about a whole module. Additionally, as this patch shows, cutting them out completely means we don't have to duplicate code from pydoc. This patch does two things: 1) It short-circuits calls to document() from within docmodule(). In practice, this only affects class and function documentation. 2) It (ab)uses the section() method to avoid adding certain sections to the module docs. These sections are for objects better discovered through introspection. With just (1), it takes a noticable fraction of a second to format the gtk docs. (Compare this to 10s with pydoc and 1s with the previous patch.) With both (1) and (2), formatting the gtk docs is essentially instantaneous. (The docs are only 28 lines long!) By mistake, an early attempt only did (2), and ran in about 4s for the gtk docs. This suggests that the time was pretty evenly split between gathering all the documentation and formatting it. Perhaps this is worth remembering if we have to look for further improvements.
I like the fact this is absolutely instant, patch looks good to me, and I don't see any problem with this heavier abbreviation of module docs from a usability point of view. I'm a little concerned that we might have residual slowness for class docs which can be pretty darn long for something like GtkTextView, but for whatever reason it doesn't seem to be a big deal. (Obviously the module docs that contained all the complete class docs were far worse!) Attachment 201417 [details] pushed as a282f4f - Use a custom documentation formatter for shorter module docs