Closed
Bug 97134
Opened 24 years ago
Closed 24 years ago
nsMsgDBView::GetCommandStatus does far to much work
Categories
(MailNews Core :: Backend, defect)
MailNews Core
Backend
Tracking
(Not tracked)
VERIFIED
WONTFIX
People
(Reporter: mike, Assigned: mike)
Details
(Keywords: perf)
Attachments
(5 files)
1.13 KB,
patch
|
Details | Diff | Splinter Review | |
1.14 KB,
patch
|
Details | Diff | Splinter Review | |
1.04 KB,
patch
|
Details | Diff | Splinter Review | |
1.60 KB,
patch
|
Details | Diff | Splinter Review | |
1.60 KB,
patch
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•24 years ago
|
||
Updated•24 years ago
|
Comment 2•24 years ago
|
||
cc: sspitzer@netscape.com for review
Comment 3•24 years ago
|
||
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
Comment 4•24 years ago
|
||
Oh, BTW:
+ PRUint32 numselected= 0;
Please make that a space on each side of the equality operator. (' = 0').
:)
Assignee | ||
Comment 5•24 years ago
|
||
Comment 6•24 years ago
|
||
Seth, can you review this patch?
Assignee | ||
Comment 7•24 years ago
|
||
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?
Assignee | ||
Comment 8•24 years ago
|
||
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
Assignee | ||
Comment 9•24 years ago
|
||
D'ohh.. wrong bug. sorry!
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 10•24 years ago
|
||
So this patch is still current and usable?
Assignee | ||
Comment 11•24 years ago
|
||
Assignee | ||
Comment 12•24 years ago
|
||
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.
Comment 13•24 years ago
|
||
Please cvs diff with the -u option for more readable patches.
Assignee | ||
Comment 14•24 years ago
|
||
Comment 15•24 years ago
|
||
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=
Assignee | ||
Comment 16•24 years ago
|
||
Comment 17•24 years ago
|
||
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.
Assignee | ||
Comment 18•24 years ago
|
||
Okay, well, with the perf work going on, I guess this is wontfix.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 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
Updated•21 years ago
|
Product: MailNews → Core
Updated•17 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•