[dev] [commits] Horde branch master updated. f61fdaee6bb5fee15abe792219b02a0947925028

[Chuck Hagenbuch]

Quoting Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Chuck Hagenbuch <chuck at horde.org>:
>
>> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>>
>>> Quoting Chuck Hagenbuch <chuck at horde.org>:
>>>
>>>> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>>>>
>>>>> Quoting Chuck Hagenbuch <chuck at horde.org>:
>>>>>
>>>>>> The branch "master" has been updated.
>>>>>> The following is a summary of the commits.
>>>>>>
>>>>>> from: 5643dee22aa524776bd6caf14625c3acc3858002
>>>>>>
>>>>>> f61fdae Right now _getRelatedTags() is the difference between  
>>>>>> my task list loading in .5 seconds and it taking 4-5 seconds to  
>>>>>> load, even after the Horde_History cache improvements. It also  
>>>>>> is getting tags that aren't from the current view because  
>>>>>> Future tasks aren't accounted for.
>>>>>>
>>>>>> -----------------------------------------------------------------------
>>>>>>
>>>>>> commit f61fdaee6bb5fee15abe792219b02a0947925028
>>>>>> Author: Chuck Hagenbuch <chuck at horde.org>
>>>>>> Date:   Wed Jul 3 00:33:57 2013 -0400
>>>>>>
>>>>>> Right now _getRelatedTags() is the difference between my task  
>>>>>> list loading in .5
>>>>>> seconds and it taking 4-5 seconds to load, even after the  
>>>>>> Horde_History cache
>>>>>> improvements. It also is getting tags that aren't from the  
>>>>>> current view because
>>>>>> Future tasks aren't accounted for.
>>>>>>
>>>>>> I think if we want to keep the related tasks top bar, we need  
>>>>>> to put that list
>>>>>> together as we go through the list of tasks, where we're  
>>>>>> already fetching the
>>>>>> tags for each task and displaying them next to each one.  
>>>>>> That'll avoid a *lot*
>>>>>> of unnecessary queries.
>>>>>
>>>>> This may be true, but can you wait until there is some fix in  
>>>>> place before removing it in the stable git branch? This way, we  
>>>>> won't accidentally remove this functionality from the next bug  
>>>>> fix release.
>>>>>
>>>>> FWIW, this is also the same mechanism that we use in all the  
>>>>> apps that use tags-as-navigation such as Trean and Ansel. I  
>>>>> think we need to improve either Content_Tagger or  
>>>>> Core_TagBrowser instead of moving the browsing functionality out  
>>>>> of it and into the application-land code.
>>>>
>>>> Yeah, I saw that it was the same mechanism, and agree it needs to  
>>>> be improved. Is this really that useful a feature right now  
>>>> though that we need to keep it in exchange for pages loading 8x  
>>>> slower? It just seems to filter the existing view, and I'm not  
>>>> sure that filtering tasks by multiple tag criteria is that  
>>>> useful. Obviously there might be another use case out there that  
>>>> heavily uses tagging to organize a ton of tasks, but anyone doing  
>>>> that right now is going to spend a LOT of time waiting.
>>>
>>> Well, I use it :)  I use it as a quasi GTD workflow. It allows me  
>>> to easily do things like "show me all the tasks that I can do at  
>>> home (since I have a "Home" tag), now , out of those tasks, show  
>>> me the tasks I can do that are related to TaskOne, now show me the  
>>> "next action" that needs to be taken on that task etc... It's  
>>> something I started doing when I was using RTM and the reason I  
>>> added tags and smart lists to Nag in the first place - I felt  
>>> dirty using a non-Horde solution ;). By naming my "project tags",  
>>> "location tags", and "requirement tags" a consistent way it is a  
>>> very versatile way of diving into a task list depending on your  
>>> current "context" - the combination of things like current  
>>> location, tools available, project due dates etc...
>>
>> Okay, that makes sense to me as a use case.
>>
>>> I don't really see any slow down; the task lists load fine for me  
>>> in approximately the same amount of time with or without the tag  
>>> browser, but maybe that is because I don't use a ton of different  
>>> tags, just a consistent handful. Though I do see that there are  
>>> improvements that need to be made.
>>
>> I don't have a lot of tags in Nag, but for each one, it triggers a  
>> listTasks() call again, which reloads the full task list, which  
>> hits Horde_History, etc. Things got better when I added memcache  
>> caching to Horde_History, which was my first attempt to track down  
>> the slow-loading task list page, but even if they're all fast  
>> memcache hits, ~5,000 Horde_History lookups (which is what I see  
>> when the tag browser is loaded) is just slow.
>
> A related question is this - Why do we need to query the history at  
> all just to display the tasklist? The created/modified data isn't  
> used anywhere on the list view. We should add parameters to listTags  
> to disable this.
>
>> So if we can't make this something that's calculated over the list,  
>> which would make it one-pass, I think we need to modify  
>> Nag_TagBrowser to use something else to do the searches so that  
>> it's not doing a full tasklist load. Is that just dropping in  
>> another object instead of Nag_Search inside Nag_TagBrowser?
>
> I've already fixed the cause of the multiple search calls in  
> Horde_Core_Tagger/Horde_Core_TagBrowser. Did you see those commits?  
> This alone should significantly speed this up for you. We should  
> still look at improving the speed by not doing History lookups  
> unless absolutely necessary as well though.

The task list is loading even faster now, even with the tag browser. Thanks!

-chuck