Thanks, Kitty. This is great research. I've forwarded it to some internal
people who are looking at it. I've asked them to comment here when we know more.
Q
On May 25, 2010, at 1:59 PM, Kitty wrote:
> I'm not sure if anyone at LL is currently working on (or aware of) this, but
> a few of the new inventory observers are really degrading the viewer's
> performance while an inventory fetch is in progress.
>
> I narrowed it down to: LLFilteredWearableListManager, LLCOFObserver and
> LLInventoryCategoriesObserver.
>
> As far as I can tell the first two are only used by the "Edit Outfit" panel
> and the latter is used to populate the "My Outfit" tab but they're running
> even when the tabs they belong to aren't active and take a long time to
> complete to the point where I've seen decoding and processing a single
> InventoryDescendants take as long as half a second (exceptional) with 1/10th
> of a second very common.
>
> The result is that the viewer either hangs for short bursts or (for me) the
> FPS drops from 50-60fps down <10fps or even less than 1fps while inventory
> is being fetched.
>
> More worrying is the fact that the stalls seem to result in incomplete
> fetches which in turn leads to perceived inventory loss (it comes short a
> few hundred to a few thousands depending).
>
> ---
>
> There's a more subtle performance issue with inventory observers as well:
> when LLInventoryModel::updateItem() gets called there's a special case for
> callings cards created by 2.0 which calls gCacheName->get(...) with a
> callback function.
>
> Since in most cases the calling cards will belong to people on the friends
> list the names are already available and the callback executes immediately
> and calls gInventory.notifyObservers() resulting in multiple invocations of
> all inventory observers per "InventoryDescendants" message.
>
> For things like the LLInventoryPanel observer it doesn't hurt since it has
> to process all the changed UUIDs anyway, but since the three listed
> inventory observers take a long time to execute it does cause a very
> noticable stall whenever a folder with a lot of calling cards is fetched.
>
> Changing gCacheName->get(...) to
>
> if (gCacheName->getFullName(id, avatar_name))
> {
> new_item->rename(avatar_name);
> mask |= LLInventoryObserver::LABEL;
> }
> else
> {
> // Fetch the currect name
> gCacheName->get(id, FALSE,
> boost::bind(&LLViewerInventoryItem::onCallingCardNameLookup, new_item.get(),
> _1, _2, _3));
> }
>
> seems the avoid the issue (the few calling cards which do need looking up
> don't seem to cause a noticeable stall for my collection of calling cards
> anyway).
>
> ---
>
> As a practical illustration (it's log on / fetch inventory / log off without
> doing anything else):
>
> Viewer-external (only difference is enabling message stats in
> llstartup.cpp):
> 2010-05-25T16:45:54Z INFO: display_stats: FPS: 3.90 <- actively fetching
> 2010-05-25T16:46:05Z INFO: display_stats: FPS: 1.80
> 2010-05-25T16:46:15Z INFO: display_stats: FPS: 1.10
> 2010-05-25T16:46:26Z INFO: display_stats: FPS: 0.80
> ...
> 2010-05-25T16:48:36Z INFO: display_stats: FPS: 50.30 <- halted fetching (=
> normal FPS)
> 2010-05-25T16:48:46Z INFO: display_stats: FPS: 51.90
> 2010-05-25T16:48:56Z INFO: display_stats: FPS: 51.00
>
> InventoryDescendents 7088 98.816109 0.102795 0.013941
>
> It reached 30,700-ish before fetching halted to nothing (and 2 minutes of
> <10fps with moments of <1fps).
>
> Patched problematic inventory observers:
> 2010-05-25T16:59:08Z INFO: display_stats: FPS: 21.60 <- actively fetching
> 2010-05-25T16:59:18Z INFO: display_stats: FPS: 20.10
> 2010-05-25T16:59:28Z INFO: display_stats: FPS: 22.90
> ...
>
> InventoryDescendents 10586 14.404209 0.067327 0.001361
>
> Fetched all of my inventory (just under 35k so 4,000 were missed above). FPS
> is down while fetching but that's probably inevitable, and it doesn't really
> cripple use of the viewer while it's happening.
>
> ---
>
> I'm not sure if patches are useful though since there different ways to
> solve it and most of the time was just finding what was causing the problem
> in the first place (ie having "My Outfits" as an inventory view didn't cause
> any observer problems in 2.0.1 and was a lot more useful and functional - no
> way to sort outfits in subfolders as the primary "con" right now).
>
> ---
>
> Lastly something that cropped up 2-3 viewer-external commits back: it
> currently takes about 3-5 seconds to open collapse/expand the sidebar for me
> (which is more or less the time it takes for an inventory floater to open)
> now which is a little bit annoying :p. It's also something that might not
> become apparent until someone has a sizeable inventory so I wanted to bring
> that up too.
>
> (Fast timers shows that it's "Find Widgets" which is responsible)
>
> Weirdest performance issue: having the "Library" root folder expanded
> results in >50% FPS loss for me for as long as the library folder is open
> (the "UI" timer jumps from 5ish to 24ish) but only if the folder is visible
> (ie scrolling up until the folder is out of view turns things normal again).
> The more library folders/items are visible, the worse performance becomes.
>
> ---
>
> Kitty
>
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
