Closed Bug 97134 Opened 24 years ago Closed 24 years ago

nsMsgDBView::GetCommandStatus does far to much work

Categories

(MailNews Core :: Backend, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED WONTFIX

People

(Reporter: mike, Assigned: mike)

Details

(Keywords: perf)

Attachments

(5 files)

nsMsgDBView::GetCommandStatus gets called at least three or four times per focus change around the mail window. It needs to know how many current selected messages there are in the thread outliner, and it does this be calling GetSelectedIndices. This builds a nsUInt32Array and the length of this is used to determine how many messages are selected. A much easier way of doing it would be to just call GetNumSelected which directly queries the thread outliner. This should be a lot faster - making mail/news seem more responsive and has the nice bonus of fixing bug 44572. Patch to follow.
Keywords: perf
Severity: minor → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: patch, review
cc: sspitzer@netscape.com for review
great catch! r=hwaara Send mscott@netscape.com email for super-review; sspitzer is on vacation. Also, make sure no focus situations regress with your patch.
Assignee: mscott → mike
Oh, BTW: + PRUint32 numselected= 0; Please make that a space on each side of the equality operator. (' = 0'). :)
Seth, can you review this patch?
I've played around with various focus transitions, and I don't think I've regressed anything. Is there a less subjective, more empirical way of doing this?
This has been fixed (poorly, IMHO ;) in bug 84260. *** This bug has been marked as a duplicate of 84260 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
D'ohh.. wrong bug. sorry!
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
So this patch is still current and usable?
bienvenu's change, probably for bugs 91352, actually started using the array returned by GetSelectedIndices(), so the new patch creates it only if needed. Note that GetCommandStatus() gets called many times (2-4 per button and command?) every focus change, so it's probably important that this is as fast as possible.
Please cvs diff with the -u option for more readable patches.
Looks like a good optimization to me. Especially in the PR_FALSE case, where we don't have to create all those unnecessary variables. Please remove the space between the if and else clauses and you have: r=hwaara. CC bienvenu for sr=
I don't think this change is worthwhile. If you think it's going to make a whit of difference as far as performance is concerned, then you will be sorely sorely disappointed. You could call this routine a few thousand times and it wouldn't approach the time it takes to paint a single toolbar icon. Also, GetSelectedIndices handles the standalone message window case, and GetNumSelected does not.
Okay, well, with the perf work going on, I guess this is wontfix.
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → WONTFIX
Trusting all in the bug to re-open if they think this _would_ be a performance gain. For now, verifying to get off QA radar.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: