Closed Bug 552167 Opened 15 years ago Closed 15 years ago

show_bug.cgi loads flagtypes from the database for each attachment

Categories

(Bugzilla :: Attachments & Requests, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Bugzilla 3.6

People

(Reporter: mkanat, Assigned: LpSolit)

Details

(Keywords: perf)

Attachments

(1 file, 3 obsolete files)

I was doing some profiling of show_bug.cgi using a local copy of the bmo database, and I was testing against bug 18574. For some reason, in the DBI profile, the following SQL is run 63 times and takes up .23 seconds: SELECT flagtypes.id,flagtypes.name,flagtypes.description,flagtypes.cc_list,flagtypes.target_type,flagtypes.sortkey,flagtypes.is_active,flagtypes.is_requestable,flagtypes.is_requesteeble,flagtypes.is_multiplicable,flagtypes.grant_group_id,flagtypes.request_group_id FROM flagtypes WHERE id IN (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) ORDER BY flagtypes.sortkey, flagtypes.name This is the largest SQL time-taker in show_bug.cgi.
Keywords: perf
Ah, I have found the culprit. Bugzilla::Attachment calls Bugzilla::Flag->_flag_types once for each attachment. This also results in the #1 time-taker in an NYTProf profile, which is the "sort" at the end of Bugzilla::Flag->_flagtypes. (Takes .5 seconds with 63 attachments.) Probably the solution is to cache Bugzilla::Attachment->_flag_types for the bug's component, in request_cache?
Attached patch v1 (obsolete) — Splinter Review
For a bug with 63 attachments, this could shave almost an entire second off of loading time.
Assignee: attach-and-request → mkanat
Status: NEW → ASSIGNED
Attachment #432322 - Flags: review?(LpSolit)
Summary: show_bug.cgi loads a bunch of flagtypes from the database over 60 times on a single page load → show_bug.cgi loads flagtypes from the database for each attachment
Comment on attachment 432322 [details] [diff] [review] v1 You mixed your patch with the template_var's one.
Attachment #432322 - Flags: review?(LpSolit) → review-
Target Milestone: Bugzilla 3.8 → Bugzilla 3.6
Attached patch v2 (obsolete) — Splinter Review
Here's the right patch. :-)
Attachment #432322 - Attachment is obsolete: true
Attachment #432324 - Flags: review?(LpSolit)
Comment on attachment 432324 [details] [diff] [review] v2 >- $self->{flag_types} = Bugzilla::Flag->_flag_types($vars); >+ $cache->{$component_id} = Bugzilla::Flag->_flag_types($vars); Bugzilla::Flag->_flag_types() returns data which is unique for each attachment. It looks for valid flag types, but also for existing flags set on the attachment, so you cannot share it between attachments.
Attachment #432324 - Flags: review?(LpSolit) → review-
(In reply to comment #5) > Bugzilla::Flag->_flag_types() returns data which is unique for each attachment. > It looks for valid flag types, but also for existing flags set on the > attachment, so you cannot share it between attachments. Okay. Then why is it being called on show_bug.cgi, a situation in which flags aren't editable?
Attached patch patch, v3 (obsolete) — Splinter Review
Could you test that, please?
Assignee: mkanat → LpSolit
Attachment #432324 - Attachment is obsolete: true
Attachment #435720 - Flags: review?(mkanat)
Comment on attachment 435720 [details] [diff] [review] patch, v3 This fixes the DB problem. However, the "sort" that happens at the end of _flag_types is still the largest time-taker for Perl code in show_bug.cgi, when there are a lot of attachments.
Attachment #435720 - Flags: review?(mkanat) → review+
I think caching them sorted and then refactoring the code a bit to use an array instead of a hash would solve the sorting problem.
Attached patch patch, v4Splinter Review
This removes the problem with sort(). In fact, all I need to do is to return $flag_types, which is already sorted thanks to FlagType->match(). And because %flagtypes contains a list of objects, when I populate this hash, I in fact populate objects from $flag_types. Data::Dumper::Dumper() says they are perfectly identical.
Attachment #435720 - Attachment is obsolete: true
Attachment #435914 - Flags: review?(mkanat)
Is the perf win significant enough to take the patch for 3.4.7?
Comment on attachment 435914 [details] [diff] [review] patch, v4 Awesome! :-)
Attachment #435914 - Flags: review?(mkanat) → review+
I'll let you decide whether you think it's safe to take this for 3.6.
Flags: approval3.6?
Flags: approval+
(In reply to comment #11) > Is the perf win significant enough to take the patch for 3.4.7? No, I don't think so.
Flags: approval3.6? → approval3.6+
Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/trunk/ modified Bugzilla/Flag.pm Committed revision 7106. Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/3.6/ modified Bugzilla/Flag.pm Committed revision 7065.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: