Closed Bug 63120 Opened 24 years ago Closed 24 years ago

Real time thread pane scrolling performance is poor

Categories

(SeaMonkey :: MailNews: Message Display, defect, P1)

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9

People

(Reporter: stephend, Assigned: sspitzer)

References

()

Details

(Keywords: perf, Whiteboard: [nsbeta1+])

It takes us 18.74 seconds on a Windows 95 machine, 133mhz, 64 MB of ram to scroll 1000 messages in a folder in real-time. Compare this with 1.89 seconds in Netscape Communicator 4.76 and 2.10 seconds with our competitor on Win32.
Per the executive review, this bug is assigned to mscott. Changing.
Assignee: putterman → mscott
Keywords: mail3, perf
OS: Windows 2000 → All
QA Contact: esther → stephend
Hardware: PC → All
Keywords: mozilla1.0
Summary: Real time thread pane scrolling speed performance is poor. → Real time thread pane scrolling performance is poor
This is a tree performance bug, like all the others...
What are the others? Do we have some tracking bug for all tree perf bugs?
Ben, sorry for getting back to you so late - yes, bug 26456, bug 22486, bug 26131, bug 22960 and bug 47645 are all mail/news performance bugs (should all be related to trees).
I've made a mail/news perf tracking bug, for all who care, it's bug # 63759. I'll be adding descriptions in that bug of each #, for quick reference.
Blocks: 63759
Dup of bug 52149?
reassigning to sspitzer. I think there is a mailnews scrolling bug out there, but it might have been closed already. marking nsbeta1+ and moving to mozilla0.8, though recognizing that this will probably be an ongoing bug that get moves to other milestones as time goes on.
Assignee: mscott → sspitzer
Priority: -- → P1
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.8
adding scott, david and mark to the cc list. accepting.
Status: NEW → ASSIGNED
my plan of attack is to start with my own "threadPane.xul", with as few style rules as possible, that is hard coded to load a 1000 message local folder. I'll work my way back up to the xul & css & js we have in Messenger, quantifying at each stage, trying to identity what is slowing down with sorting and scrolling. I'll report any findings here.
Keywords: nsbeta1
I've been doing some work in bug 53620 to improve the performance of style resolution in general, and I think I have made some good progress toward speeding up tree scrolling. Setch, it might be worth you while to check out the patch I've attached there - I have not been able to Quantify it yet, but David Baron has done some more primitive profiling and saw a significant improvement.
moving to mozilla0.9
Target Milestone: mozilla0.8 → mozilla0.9
mark, I'm working on multiple delete performance right now. but don't get me wrong, I'm psyched about the work you are doing in the style system. I'll try out your patch in #53620 when I get back to this particular performance problem.
Note: This is already fixed in the mail performance branch. When we merge, I can verify this as fixed. See the URL above.
fixed. hats off to hyatt, mscott and bienvenu.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
VERIFIED FIXED per my results for all platforms at: http://www.mozilla.org/mailnews/win_performance_results.html If we have additional enhancements, those need to be filed seperately.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.