Performance: revamp HS' cache system

I go a step further: client-side caching. See http://drupal.org/node/284638 and http://drupal.org/node/300572
HTML 5 client-side databases are already supported! Unfortunately, this has only been implemented in Safari/WebKit so far.

Also, AJAX isn't slow. It isn't very noticeable and definitely not annoying at http://wimleers.com/demo/hierarchical-select/taxonomy (there it takes about 0.5 second). So probably it's your server that's too slow … or you've got a huge taxonomy, in which case it might indeed be slow.
So, do you have a huge taxonomy?

Ah well, yes, you could create a server-side cache. I'd recommend altering the hs_taxonomy_hierarchical_select_children() function in the hs_taxonomy.module file and add caching in there. Then post the patch here and post the statistics of the improvements.

Closing while cleaning up the issue queue. Feel free to reopen.

That'll result in even worse performance. Suppose you have 15 items in the next level. You want to load the next 2 levels. That means 16 subtrees will have to be retrieved.

Client-side caching (as said, #284638: New cache system: JS and #300572: New cache system: Google Gears) make much more sense.

True. My wording was somewhat unfortunate. The loading of the page would take very, very long. But of course, you could use a server-side cache system as you suggested. But then the problem is the syncing with the client-side cache, as you also said. However, it's possible to work around that, by making the client-side cache system smarter.

Let's make this an umbrella issue :)

From my POV, the requirements are:
- We want to be able to have a server-side cache when the hierarchy is not too big.
- Each HS implementation must be able to tell the server-side cache when it should update a subtree.
- We want to be the client-side cache to update automatically whenever the server-side cache has been updated.
- The client-side cache must not be invalidated completely, each subtree must be updatable separately.

Comments?

Oh and what should happen first, is #528156: Performance: Remove Hierarchical Select's form cache and don't reconstruct the entire form anymore. Especially see http://drupal.org/node/528156#comment-1860876 in that issue.

This is a performance feature.

And will not be for HS 3.0 for D6.

Instead of writing code for Client-side databases, Google Gears and whatnot, use jQuery jStore instead, which provides an abstraction for all of these: http://code.google.com/p/jquery-jstore/.

In addition to the explanation in #8:

Using a scheme like:
* invalidate the entire cache of a hierarchy if changes are made on the vocabulary settings page
* when a term is changed, invalidate the tree below it
* when a term is added, invalidate the tree above it

As mentioned in http://drupal.org/node/235932#comment-827377.

(Source: #253301: Client-side cache: more advanced cache invalidation.)

And JSON requests should be made cacheable (original issue: #228174: Make JSON requests cacheable).

I have 1000+ terms and each term is under multiple parents (5-10 multiple parents).
It takes awhile for a selection to load. I hope this will fix this performance issue. Thanks!

Subscribing

As advancement of #544324: Performance: Improve multiple item processing in big taxonomy hierarchy setups. we can also make server-side cache for processed data of HS hooks: rendered children, children count etc.

subscribing

Subscribing.

Tagging for HS4. Will be included in the HS4 roadmap: http://drupal.org/node/1052670.

This will happen in the 7.x branch.

This may not happen but I don't think being in postponed will help it. setting back to active if people are planning on working on it. Or maybe close it?