Melinda Green wrote:
In the official viewer, the observers ("listeners") do the sort. There is common code to notify observers after anything is added or removed to the active list, like in LLGestureManager. When the one for the combo box is notified, it reads the active list raw and entirely, which it then sorts. The code surely wasn't a problem for those with small inventories. Now, we have to consider those with well over 10,000 items, and the straightforward means does need a change. What I did wasn't added complexity. Instead of a call to notify observers, I made an event for when an item is added to an active list and another event for when it is removed. The event is called with the UUID of the item, so that code could be implemented to avoid a complete raw read on the list. For example, one could use the event to queue the UUID to a worker thread, and it would be expected the other thread would never need to lock or do raw read on the active list because it has that UUID. I didn't do the thread part, yet. Right now, both events call a single function called "touched." This basically replaces the notify->sort flow with a notify->touch flow. If that flag ever gets out of sync, then the list won't appear sorted. Although there was previously a performance issue, that type of synchronization bug was at least not possible. The possibility of that kind of bug happening is the same possibility of the notify->sort call not being made. Actually, I call the events anytime there is something added or removed from the active list. The notify->sort is called near the end of each function that modifies the active list. The notify->sort method doesn't know if an item has been added or removed, or if any changes were actually made. The two events I put in could literally replace the active list, but it isn't needed to go that far, yet. Was the performance savings worth the complexity? Maybe so but I'd really rather find a solution with less risk. It was a pretty simple change. There is always added complexity when common code is used, like the observer methods. The code may seem simple to understand since it is common code, but it is like the use of a sledge hammer, a common tool, on a nail instead of carpenters hammer. You wanna hold that nail for me? It's not a complex question. =) Like perhaps only sorting when the drop-down is opened. Yes. I put an event box over the combo box. It actually isn't sorted until someone mouses over the combo box. It may not be the best time to sort the list, but I didn't want to add any extra complexity to find out when is the best time. I applied the just-in-time method. On my avatar with a couple hundred triggers, you don't notice the sort happens. Once the sort is done, the event box is removed. Since it doesn't sort on every time the active list is touched, this already has the advantage to avoid sorts on duplicate items or duplicate triggers or on null items. The just-in-time method is less complex to achieve other advantages. My point is not on what is the best solution to this problem but simply that sometimes it's worth suffering some extra code complexity and the inevitable future bugs that complexity always brings. Given that the project for the Gesture Tracker may add a couple hundred more gestures for everybody that wants to get all the facial expressions, I'm sure the complexity of the current code will cause issues with the Gesture Tracker. Tigro already spotted how invetory items are still not available in his list of 30,000 items. How will people feel when they try to nod and expect the gesture tracker to work, but their avatar on screen doesn't move because the information for the nods got dropped in login. Since the notify->sort method only updates the sort when assets successfully come in (and not be dropped), it is added complexity for that user to figure out that the reason their avatar doesn't nod is because the gesture info got dropped, but there is nothing to tell them that their desired gesture was dropped. Some of such users may know they have to figure out how to manually reset the inventory load to get the gestures, but do you see the sledge hammer complexity here? Bugs such as this one that seems to make you so upset. What I don't understand is what your point is in insulting the code. Lots of the viewer code is beautiful and lots of it is messy and fragile, but calling it all stupid is almost the same as calling the developers dumb which is not what we need. -Melinda _______________________________________________ Yes, we know what it is like to be made to look stupid (and be made an object that others make fun of ), or even be a center piece for blame or be rudely, incessantly, and publicly called or pointed-out as wrong. Unlike LL developers that are being paid to make beautiful code, at this point, I'm not being paid to make beautiful open source code. For what beautiful open source code I and others do offer, I hope it is appreciated, but I don't do it for appreciation. Some do it on their spare time, I do it with hope. |
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
