Several changes to speed up the ShortcutsProvider:
(1) Bail immediately when BEST_MATCH is requested (as is the case for the AutocompleteClassifier) as the ShortcutsProvider does not currently allow matches to score highly enough to be "best". (2) Check for input text that's a prefix of the shortcut in question, and mark the whole prefix as a match at once. This reduces the number of cases where we have both lots of input words AND a long unclassified chunk of output string (the case where things are slow). (3) Rewrite the general-case matching algorithm to be noticeably faster. (Not sure of the complexity analysis but I think the worst case is more like O(n*n) than the previous O(m*n*n) and the average case should be much faster than that. With the test profile and disabling the above two optimizations, typing a letter in my debug build resulted in a hang of about 2 seconds as opposed to several minutes.) We could probably still do better; in particular, one optimization we could make for all the providers would be to provide them a conservative estimate of how many total characters would be visible in the omnibox dropdown and then have them trim the contents and description fields accordingly before matching. However, a true conservative estimate -- which would assume that we had e.g. a string of 'i's -- would in the worst case still be several thousand characters wide, I don't want to do the plumbing work, and this optimization seems unnecessary at the moment anyway. BUG=138242 TEST=none Review URL: https://chromiumcodereview.appspot.com/10831004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@148444 0039d316-1c4b-4281-b951-d872f2087c98
Showing
This diff is collapsed.
Please register or sign in to comment