Open
Bug 330917
Opened 19 years ago
Updated 2 years ago
nsHTMLSelectElement::VerifyOptionsArray is too slow to be DEBUG for everybody
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
NEW
People
(Reporter: dbaron, Unassigned)
References
()
Details
(Keywords: perf)
Bug 324918 added #ifdef DEBUG code to verify the options array for every mutation of a select, or something like that.
I question whether this debugging code should be #ifdef DEBUG rather than #ifdef DEBUG_somebody. It makes DEBUG builds unusably slow loading pages like https://bugzilla.redhat.com/bugzilla/query.cgi?format=advanced -- after dealing with it for a bit I went to the trouble of doing a profile to find this DEBUG code. We do want DEBUG builds to be fast enough to be usable, and I don't think this check meets those criteria.
Hmm.. that surprices me but i'll take your word for it.
I think it'd be useless as a DEBUG_sicking or something like that because any one person won't hit enough pages to detect obscure bugs.
So either we should just remove this entierly, or we could add some sort of global counter so that we only verify once out of every 10 mutations or something.
Comment 2•18 years ago
|
||
> Hmm.. that surprices me but i'll take your word for it.
Bugzilla query pages do thousands of <select> mutations as they load, on very long <select>s. So performance issues on them with this code don't surprise me in the least.
I do think doing the check every 50-100 mutations is an ok. Or possibly doing the check off an event so it's somewhat coalesced?
Updated•2 years ago
|
Severity: normal → S3
Comment 3•2 years ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Assignee: jonas → nobody
You need to log in
before you can comment on or make changes to this bug.
Description
•