You are viewing an historical archive of past issues. Please report new issues to the appropriate project issue tracker on GitHub.

Bug #342: CPU Usage stuck at 95-100% when populating Global Menu with very large libraries

Kind bug
Product Synergy Advance
When Created , updated
Status open
Reporter john
Tags no tags

Description

I just put a fresh copy of OS X 10.4.3 on my desktop and since then Synergy Advance will not use less than 95% of the processor, regardless of weather iTunes is on or not it still uses the same amount of processor, any attempt to access the Menubar icon results in a "Synergy Advance (Not Responding)" notice in Activity Monitor. As was mentioned in a previous report I have approximately 60-70,000 tracks in my iTunes Library which reside on AFP mounted drives, other than that there are no strange system extensions or hacks that would interfere with iTunes or Synergy Advance.

Comments

  1. john

    Created an attachment (id=45) Sample #1 of Synergy Advance (while "Not Responding")

  2. john

    Created an attachment (id=46) Sample #2 of Synergy Advance (prior to "Not Responding")

  3. Greg Hurrell

    Thanks for the report and the samples, John.

    I am not sure how much can be done about this, given the size of the library. The parsing of the library occurs in a separate thread, but there is a part of the process which cannot be done in a background thread (the actual insertion of menu items into the menu) and must be done on the main thread. Your sample shows that the program is spending most of the time doing the insertions.

    The next release has new code for inserting items into the menu; see this article:

    https://wincent.dev/a/about/wincent/weblog/archives/2005/08/big_menus_reall.php

    I'm using a different API for inserting items into the menu. I don't know whether this will help, but once you've tested the new release let me know whether it makes a difference. I've done some testing and identified that there is lots of room for optimization in this API, and I've filed a bug report with Apple about it; basically: they call the API for the entire menu, even if it is thousands of items in size and only a small fraction of the menu will be visible on screen at any time. If they make a change to the API so that it only invokes the API for visible menu items then we'll see an absolutely massive speedup (and reduction in memory usage as well).

    If it turns out that there's nothing that can be done to speed it up (probably because of the combination of it being a huge library AND it being AFP mounted) then you may have to simply turn off the offending menu items. I am working an a customization module that will allow you to remove/add/reorder items from the menu. You'll be able to get rid of whichever menu item is soaking up the CPU (probably the "Playlists" menu item).

  4. john

    Created an attachment (id=55) Sample of SA 0.4b2 while not responding to menu bar item

  5. john

    Added a sample of 0.4b2 while not responding to the initial use of the menu bar item. The good news is that after 60-90 seconds S.A. pulls out of not responding and goes back to a stable state with cpu usage within an acceptable range (3-10%), and subsequent uses of the menu bar item do not re-produce the extremely high cpu usage. Additionally I can now open the Artists submenu and flawlessly (no hiccups or nasty rendering glitches) scroll through 10,000+ artists.

  6. Greg Hurrell

    (From update of attachment 55) Correcting MIME type

  7. Greg Hurrell

    Thanks for attaching the new sample, John.

    You can expect this to improve in the near future. CPU will always be high when churning through an extremely large library, but I should be able to remove the initial unresponsiveness while preparing the menu.

    Bug #387 and bug #389 were the highest priorities, but now they are fixed and I'll get a new beta out within the next couple of days. Then I'll turn my attention to this bug. I was actually working on this before, then went on a nearly three month side trip re-writing the communications engine... hopefully it all means I'll have a rock-solid foundation upon which to layer new features.

  8. Greg Hurrell

    Changing assignment to reflect my new email address.

    https://wincent.dev/a/news/archives/2006/05/change_of_email.php

Add a comment

Comments are now closed for this issue.

Menu