Closed Bug 99387 Opened 23 years ago Closed 23 years ago

turbo gain minimized

Categories

(SeaMonkey :: General, defect)

x86
Windows NT
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.5

People

(Reporter: ccarlen, Assigned: ccarlen)

References

Details

(Whiteboard: PDT, CHECKED INTO TRUNK)

Attachments

(1 file, 1 obsolete file)

The cause is the fix for bug 86021. Shutting down the current profile, done in order to flush passwords, log out of mail servers and AIM, also resets some things which have a lot of overhead to re-initialize next time around. I have a patch for this which avoids that overhead always for one profile or with multiple profiles, at least when the same profile is used as last time.
Is this targted for 0.9.4?
The patch is testing out well. We should be back to where we were in terms of perf with one profile or choosing the same profile amongst multiple profiles. Have to do an optimized build an verify. I have a UI question: With this patch in place and multiple profiles, the skin of the profle UI is not always the default skin. The profile UI comes up in the *last* skin used. Not sure if this is objectionable or not.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.4
Attached patch patch (obsolete) (deleted) — Splinter Review
Bhuvan, Seth - can you r/sr?
Blocks: 99488
Keywords: nsbranch+
per PDT
r=bhuvan. Conrad, As you already know about the various scenarios that we have in profile manager, it will be better if you can run test scenarios (a matrix of tests) with single/multiple profile and mail accounts. Adding German to the cc list for the UI issue brought up.
0.9.4 is out the door.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Don't knokw if this is related, but I'm seeing Modern buttons in Mail, though I have Classic selected. Persists across restarts/reboots.
If it persists across reboots, it's not related. Probably a profile created with ns and used with mozilla. It's a chrome problem (bug # unknown but there is one)
doron - if you want to remain QA contact on these bugs, let me know. Grace has been QA'ing the turbo mode feature so I assigned to her.
QA Contact: doronr → gbush
Blocks: 75599
No longer blocks: 75599
Comment on attachment 49180 [details] [diff] [review] patch sr=mscott. But please make sure you've coordinated with our QA team about how to test this fix so they are in the loop. Thanks.
Attachment #49180 - Flags: superreview+
Attached patch updated patch (deleted) — Splinter Review
The updated patch is equivalent to the first. It has been updated because of conflicts with recent checkins.
cc: terri, esther, suzanne, (and grace) to help test this feature. Conrad had sent email on this. I'll forward to you. Conrad - let us know when this has been checked in. It would be much better if we can get this checked in and then tested on an actual release build so that we can avoid double test work to test on an experimental build and then run the same tests on the release build after checkin. This is somewhat of an extensive area. Do you agree?)
Blocks: 75599
Can we get this on the trunk, and start testing it there?
Yes - I have to update from scc's massive checkin first.
Pls uopdate Patch Status with "has-review" and "has-super-review".
Pls get it on the trunk and pound on it.
Whiteboard: PDT
Comment on attachment 49853 [details] [diff] [review] updated patch previous patch got the actual r=/sr= but this patch has no real changes - just update.
Attachment #49853 - Flags: review+
Attachment #49853 - Flags: superreview+
Attachment #49180 - Attachment is obsolete: true
*** Bug 100689 has been marked as a duplicate of this bug. ***
Got the r= on the bugscape portion of this. Ready to go on the trunk now.
Updating status.
Whiteboard: PDT → PDT, CHECKED INTO TRUNK
*** Bug 100543 has been marked as a duplicate of this bug. ***
Marking fixed because it's not going into the branch because multiple proifle support is coming out.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
I'm not sure how this can be verified as fixed. Bugs 99117 & 100385 which were caused by supporting multiple profiles are not fixed. If this bug is for supporting multiple profiles with turbo on, it's not fixed. On by default or on by mannually selecting it, we still have problems selecting from the Profile Manager. Please let me know what the criteria is for verifying this as fixed.
> If this bug is for supporting multiple profiles with turbo on, it's not fixed It's not - it's about the perf loss aspect of that. This is fixed (trunk only) if: (1) The time from clicking the icon in the systray until the time that the first window appears is close to nothing (on a 750 Mhz PIII anyway). In terms of the performance, this action should take only as long as builds from before 08/29. This is true if there is one profile or if the profile chosen is the same one as the previous launch. If you switch profiles, it's slower. It should also, on closing the last window: you have only one profile and: (2) Mail passwords are forgotten on closing the last window (3) HTTP passwords are forgotten on closing the last window
verifying on trunk build performance improved, passwords forgotten as noted
Status: RESOLVED → VERIFIED
No longer blocks: 75599
Blocks: 75599
No longer blocks: 99488
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: