[opensource-dev] Call for stability patches

Kitty sldev at catznip.com
Tue May 25 10:59:53 PDT 2010


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



More information about the opensource-dev mailing list