User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060512 Minefield/3.0a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060512 Minefield/3.0a1 In Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060512 Minefield/3.0a1 ID:2006051208 [cairo], I see CPU spikes (~25% cpu usage) at regular interval (~20 sec) with mouse out of Firefox and Firefox doing nothing Reproducible: Always Steps to Reproduce: 1. Launch Firefox 2. Monitor CPU usage of Firefox (windows taskmgr or process explorer) 3. Move the mouse out of Firefox window, wait for possible RSS reload etç 4. Watch CPU usage Actual Results: Spikes every 20 sec. Expected Results: No spikes (Noted Win2k) as a win2k user confirmed on mozillazine Happens even in -safe-mode

On this screenshot don't take into account Firefox startup CPU usage, idling begin when Private bytes history is constant.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060512 Minefield/3.0a1 ID:2006051211 [cairo] same here, but 10 sec cycle 10 secs after startup the live bookmarks are loaded after that every 10 secs a spike (seeing the same with a 20060501 build, even is -safe-mode)

Additionnal information: the spike comes from the firefox.exe!jpeg_fdct_slow+0x88d9 thread Thread Stack (according to process explorer): ntoskrnl.exe!ExReleaseResourceLite+0x206 win32k.sys+0x2fa0 win32k.sys+0x37a6 win32k.sys+0x37c3 ntdll.dll!KiFastSystemCallRet firefox.exe!DeviceContextImpl::AddRef+0x247b0

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060512 Minefield/3.0a1 I see none of this: one line of 1% cpu usage with irregular little jumps to 2%. I have not many livemarks; 7 or so.

I tried the 20060428 Bon Echo nightly build (Places ENABLED) and it shows the same spikes With the 20060428 Bon Echo nightly build (Places DISABLED) the spikes are gone (unfortunately I couldn't find any Trunk builds with places disabled)

(In reply to comment #6) I tried the 20060428 Bon Echo nightly build (Places ENABLED) and it shows the same spikes With the <del>20060428</del> 20060429 Bon Echo nightly build (Places DISABLED) the spikes are gone

My guess is the livemarks service. http://lxr.mozilla.org/seamonkey/source/browser/components/places/src/nsLivemarkService.cpp#134 You might want to try commenting out the timer to see if the problem goes away. This was basically copied from the old service, but the new one is doing heavier-weight DB ops. If this is the problem, we should probably be smarter about updating, because we know when the next livemark will expire. Then we should just set the timer for that amount instead of a periodic timer. Also, I don't think DB ops are strictly necessary, so we should optimize those out by caching the expiration times.

(In reply to comment #8) > My guess is the livemarks service. > http://lxr.mozilla.org/seamonkey/source/browser/components/places/src/nsLivemarkService.cpp#134 > > You might want to try commenting out the timer to see if the problem goes away. > This was basically copied from the old service, but the new one is doing > heavier-weight DB ops. > So, I tried to reproduce on my debug build (2006051101) and I had difficulties to reproduce in a first attempt. So I copied my bookmarks_history.sqlite file from my "all-day usage" profile (where I observed this bug) to the debug profile and was able to reproduce. Following your direction I added a breakpoint @ nsLivemarkService::FireTimer(nsITimer *, void *) and my debuger breaks every time I should have a spike. If I hit continue the spike appears. So in conclusion, you are totally right the problem is related to this repeated timer.

When this optimization is done, we should be sure that all the changes get committed in one transaction so shutdown isn't delayed too much if you shut down soon after an update.

I had a dickens of a time finding out why my installation of Fx ran so slowly. I went to the Mozdev forums and chatrooms and tried all the fixes to no evail. As I became more attuned to Fx inner workings, and thanks to Firebug (indispensible) I found out this: If you have more than a few Live bookmarks, get rid of them and rely on extensions or web-based aggregators to read your feeds. Apparently Fx was continually servicing all of my livemarks and it sucked up my resources. It was chewing up 90% plus CPU cycles for minutes at a time. Making all of the livemarks regular bookmarks solved the problem.

Could you provide a preference for setting the update interval for livemarks? hourly, daily, weekly. Better yet, give the user an option to start the update manually.

This seems fixed to me should this bug be closed?

And if it wasn't fixed back in September, it was definitely fixed in bug 419832.

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv