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?

My site has it at the same speed as yours, but when everything else happens instantaneously, and when my hierarchy is deep, even this little delay is annoying as heck and causes users to complain.

I do think there should be some kind of server-side precache, I know about the client side caching, but there should be more. {erhaps the tax should be cached on cron run, and only refreshed if a new term is added.

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.

I still can't do this, but I'm going to open it anyway.

I'm no longer sure if it makes sense to have a server side cache, I think even if it's based on cron it has possibilities for syncing poorly.

What makes most sense to me is selectable levels of preloading. So whenever a term is selected, the next 2 levels are ajax loaded as soon as initial loading is complete.

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.

How would it impact performance? The page is already loaded. It'll just make future loading faster.

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?

Thanks for prioritizing this issue. :)

Your plans sound great. I hope it'll be enough to fix the speed issue though.

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).