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.

Bhuvan, Seth - can you r/sr?

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.

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.

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.

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?)

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.

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.

*** 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.

*** 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.

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