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

[Michael J Rubinsky]

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.


-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-keys
Size: 2200 bytes
Desc: PGP Public Key
URL: <http://lists.horde.org/archives/dev/attachments/20130715/59d9addc/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6062 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/dev/attachments/20130715/59d9addc/attachment-0001.bin>