I understand that the core Seamonkey development team reads a lot of the postings on this newsgroup, so I wanted to take this opportunity to post some feedback on a particular issue regarding the newly released Seamonkey 2.0 suite that has otherwise made what has been a excellent refinement of recent Seamonkey releases, into something that has been difficult and frustrating to use, especially when these issues did not occur at all whatsoever with all past versions of Seamonkey, Mozilla suite and even as far back as Netscape 6 and 7.
SEAMONKEY 2.0 ISSUE SUMMARY - In short, SM 2.0 for some reason consumes large bursts of CPU power, repeating at fairly frequent intervals (anywhere from once every half a minute to once every few minutes), and these events appears to bring the Seamonkey application thread to its knees, resulting in frequent temporary stalling, freezing and pausing of the application for long periods, even when running on a modern powerful high clock speed multi-core CPU system that capably handles just about any other demanding application I could throw at it. HARDWARE / OS OVERVIEW - I have been running SM 2.0 on (as I have with SM 1.X for many months) - a high performance major brand name motherboard with a multi-core (more than 2 cores) CPU set at a clock speed of 3.0 GHz, 2 GB of RAM, Windows XP SP-3 in a highly optimized configuration and environment, and more than ample Windows swap file size. Normally, this CPU is running in Window's energy efficient power mode and the AMD Cool and Quiet CPU drivers which dynamically throttle CPU clock speed as needed. I consider myself a power user. OBSERVATIONS / SYMPTOMS I have used SM 2.0 since the day of its official release, and while I have had no real issues whatsoever setting up SM 2.0 and manually migrating all my existing preferences, mail and newsgroup files and other browser / address book files, shortly after using SM 2.0 I discovered that the entire application suite FREQUENTLY STALLS / PAUSES even when I perform the simplest tasks, which may include: * Flipping through different windows / components of the suite, including browser window, mail window, mail composition window, address book, etc * Simple typing in a mail composition window * Copying and pasting text blocks (e.g. mail composition / editing) * Highlighting and deleted text blocks (e.g. mail composition / editing) * Scrolling through a web page already fully loaded or text in a mail composition window, using mouse wheel * Retarded response when clicking on links * Multi-media playback within browser window (e.g. Flash FLV video) I would like to emphasize that these stalling symptoms above occur when such tasks are either performed or are performed during the reoccuring stalling period of the application suite. Furthermore, I have absolutely NOT experienced ANY of these problems for all the years I have used Netscape 6, 7, the Mozilla suite and all Seamonkey 1.X releases. This issue occurs even when the operating system has just been freshly rebooted AND SM 2.0 is the ONLY application running. FURTHER INVESTIGATION I decided to investigate this stalling issue further and began to use SM 2.0 while running the AMD Power Monitor, which graphically displays all CPU core utilization percentage on a moment to moment basis within a small window. Meanwhile, I kept SM 2.0 as the ONLY running application on the system to ensure that it was the only major source of system load. Normally, with the Windows-XP power mode set to a power efficient mode (i.e. minimal power management mode), all cores are running at an idle speed of about 800 MHz (with a maximum core speed of 3 GHz when the load requires it). With virtually all of the applications I run on my system, including multimedia players, most of the time all cores are at a relaxed 800 MHz and occasionally one or two cores may be ramping up to 1.6 GHz, and very infrequently and very briefly one of the cores may ramp up to 3 GHz. Under this energy efficient mode, the system handles a heavily loaded SM 1.X release just fine with a high number of browser tabs loaded with heavy pages, multimedia playing on one or more tabs and the mail window running as well. But with SM 2.0, the stalling occurs frequently. I decided to set the Windows-XP power mode to ALWAYS ON mode so that all CPU cores would run at an idle clock speed of 3 GHz. Interesingly, in this mode, the stalling symptom of SM 2.0 was reduced somewhat. However, it was STILL NOT completely eliminated, and furthermore, observation of the AMD power monitor utility also indicates that one or more CPU cores frequently shows a very high core load percentage (even when running at a full 3.0 GHz core speed) that coincides with WHENEVER SM 2.0 stalls. This is particularly noticable (but not exclusively limited to) during playback of vidoes such as Flash FLV within the Flash plug-in inside a SM 2.0 browser tab / window, where, during stalling, the video frame rate would frequently drop to zero with only audio playing, and it could take anywhere from several to more than ten seconds for SM 2.0 stalling to end, and the video would skip huge number of frames to quickly catch up with the audio. Again I emphasize this video playback issue is PART of the stalling problem and it NOT exclusively the only operating condition of SM 2.0 that causes stalling, but rather, an operating condition that especially amplifies the crippling severity of the SM 2.0 suite stalling issue. Whatever the application is doing during those bursts of high CPU consumption periods once every so often, it is using an inordinate amount of CPU power and even on a fast multi-core system, it cannot overcome the demands of those power bursts, thus causing application stalls. When I was using SM 1.X, I have noticed that the older suite had the behaviour of having ONE SHORT STALL which usually occurs shortly after I use the application. During the stall with SM 1.1, I noticed the hard disc activity light comes on for a few seconds, presumably something to do with the application initially demand OS resources which results in Windows swap file space access or allocation. But with SM 1.1, after this event, the suite runs very smoothly on the very same system, at dynamically throttled, energy efficient power mode of Win-XP (i.e. most of the time all CPU cores are running at mostly 800 MHz). The situation with SM 2.0, is quite intolerable and absolutely prevents me from recommending a number of SM 1.X users which I have supported, to move to SM 2.X until this issue is resolved. I hope the Seamonkey development team will be able to understand what the coding within SM 2.0 does that may be the cause of the above described problems. I do not appear to be the only person having this problem. I have read in other support forums that other users also experience similar symptoms when SM 2.0 is used in some of the tasks I have listed above. _______________________________________________ support-seamonkey mailing list [email protected] https://lists.mozilla.org/listinfo/support-seamonkey
