Closed Bug 790216 Opened 8 years ago Closed 7 years ago

Optimize global search results

Categories

(DevTools :: Debugger, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 19

People

(Reporter: vporof, Assigned: vporof)

References

Details

Attachments

(1 file)

Profiler shows 63.9% hotness in DVGS__createScriptResultsUI. As expected, the algorithm to find the results is pretty fast, displaying the results is not. I think maybe batching up this part and using document fragments should help.

http://people.mozilla.com/~bgirard/cleopatra/?report=56c9da3f58c1ba82ddd3bdaf04f4fc884820af59
Upon further testing, it seems that:
77.6% is in createScriptResultsUI
5.6% + 3.1% is ThreadActor duty (initial scripts fetching/caching)
2.5% is the actual search

Wow. UI is *really* slow.
Assignee: nobody → vporof
Status: NEW → ASSIGNED
Priority: -- → P2
Using document fragments provide exactly *no* speedup in this case. The reason for this is because they mostly help only dealing with multiple node appends triggering reflows. For example, doing
>> parent.append(thing);
>> thing.append(otherThing);
would be slow and benefit from fragments, but
>> thing.apend(otehrThing);
>> parent.append(thing);
has no speedup because it's essentially doing the same stuff under the hood.

The current implementation in the global search makes use of the latter approach. I did some benchmarking, and the results are (avg. after 10 runs searching for 'a' in a ~1mb Lorem Ipsum file with ~2500 matches):

~7300ms with fragments
~7310ms without fragments

The good news is that I managed to track the slowdown to a different place:
.string[match=true] {
  ...
  transform: scale(1, 1);
}
.string[match=true][focused] {
  ...
  transform: scale(1.75, 1.75);
}

Even though these transitions aren't shown the first time the results are shown (only on click/focus), the applied scale(1, 1) transform is causing serious slowdowns.

Removing that rule and applying it lazily provides an almost 1.5x speed increase:
~5100ms with/without fragments

Moreover, if I don't expand the source results, there's a 10x speed increase:
~520ms

So my suggestion is:
* lazily apply the transform scale rule
* don't automatically expand results for sources with more than 200 matches

Is 200 a good number? I seems pretty random, but feels right. What do you think?
Summary: Optimize global search results to use document fragments → Optimize global search results
(For the record, I also tried a different approach: caching a blueprint node which I'd clone for each result, modifying it with the new text contents instead of creating it dynamically each time, but that resulted in a 3-500ms slowdown...)
(In reply to Victor Porof [:vp] from comment #2)
> So my suggestion is:
> * lazily apply the transform scale rule
> * don't automatically expand results for sources with more than 200 matches
> 
> Is 200 a good number? I seems pretty random, but feels right. What do you
> think?

I would be fine with 10-20 even, but if you get decent speed with 200, I'll be more than happy!
Note to self: Investigate other possible slowdowns caused by orion resize events triggered while creating the search results UI.
Attached patch v1Splinter Review
Made the changes described above.
Attachment #675035 - Flags: review?(past)
Depends on: 707302
Comment on attachment 675035 [details] [diff] [review]
v1

Review of attachment 675035 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, but I've noticed something seemingly related to this change:

1) Visit http://harthur.github.com/wwcode/
2) Search for "!sea"
3) The match in wwcode.js is not expanded even though there is only a single match in that file.
Attachment #675035 - Flags: review?(past) → review+
(In reply to Panos Astithas [:past] from comment #8)
> Comment on attachment 675035 [details] [diff] [review]
> v1
> 
> Review of attachment 675035 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Looks good, but I've noticed something seemingly related to this change:
> 
> 1) Visit http://harthur.github.com/wwcode/
> 2) Search for "!sea"
> 3) The match in wwcode.js is not expanded even though there is only a single
> match in that file.

Yes, that happened until now as well. Only the first result is expanded by default.
I guess I could also automatically expand results with a low number of entries without performance issues. Shall I do it here or in a followup?
(In reply to Victor Porof [:vp] from comment #9)
> Yes, that happened until now as well. Only the first result is expanded by
> default.
> I guess I could also automatically expand results with a low number of
> entries without performance issues. Shall I do it here or in a followup?

I filed bug 805759 since this is a ux enhancement not a performance issue addressed by this bug.
https://hg.mozilla.org/mozilla-central/rev/86defc974ef8
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 19
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.