Speed up with 30k elements taxonomies?

Hm, the only function where a lot of data may be loaded is shs_term_get_parents() in shs.module. This is called on load of the form element.
Maybe you can change this accordingly?

I recently committed some changes to improve performance for non-translatable vocabularies.
In a test I've done right now, the first level (15.000 terms) has been loaded after 15 seconds ... so I guess something else is blocking here.

I'm also experiencing performance issues with big taxonomies which is preventing to use the module. The problem seems related to the fact that all the taxonomy terms at all depth are being loaded into the select field in the form.
My page is taking about 10+ seconds to load with shs enabled and the taxonomy has about 25 items at first level (8k total).
Any suggestion?

@filippo.ledda How long does the site take to load without SHS? I would bet it is nearly the same, since the terms are loaded into the original widget.

Thanks for your fast response. With autocomplete it’s like any normal page, less than 1sec.
If the module is supposed to load all items client side I really don’t see the point of using shs over cshs. The main advantage I see of working server side is loading items where and when needed! I think this is one of the worst kind of bugs: just to give a picture, in my case I promised a hs feature to my client for places/cities which I cannot deliver because of this problem. The sole existence of a “server side” hs module may be also preventing the community in making a proper server side module.
I’m willing to help solve the problem if you think the module structure allows a different approach. Otherwise I think a warning on the module page for big taxonomies would save people wasting time

I don't speak of the autocomplete widget, please try the default dropdown. Not SHS is loading all terms, Drupal core does.

Of course the default dropdown loads all terms, that's what it's meant to do.
When I use a different widget what I expect is a different behavior from core widgets, that's why I use it!
I don't mean that this module should necessary adopt a fully server-side approach, from your words I understand that it's too much bound with core select to do so.
In this case the description of the module is quite misleading and in my case it costed a wrong analysis and wasted time.

@filippo.ledda: have you done anything to get around this issue? Facing the same problem :(

@pratip.gosh what I finally did was using autocomplete. IMHO this module is useless without this fixed, cshs has much better UI for small taxonomies.

Correct. Moreover, I feel that this module is in no way a very feasible alternative to the Hierarchical Select module which had a lot of options and catered very large taxonomies also by asynchronous processing of the terms from the first instance.

I am also not sure why this is not eligible as a Bug rather than a Support Request.

I've just come across this big performance issue when trying to load a field with 16k+ terms.

I can see what the module is going, it's simply masking over the default select field to make it look a bit better but a different method will definitely be required such large taxonomies.

I was hoping that I wouldn't need to hack together a workaround for this as a deadline looms...

For a workaround, I cloned OptionsShsWidget.php into my custom module then in getOptions() added:

$cid = 'my_module_terms:' . \Drupal::languageManager()
            ->getCurrentLanguage()
            ->getId();
        $data = NULL;
        if ($cache = \Drupal::cache()
          ->get($cid)) {
          $options = $cache->data;

        }
        else {
          $options = parent::getOptions($entity);
          \Drupal::cache()
            ->set($cid, $options);
        }
        // Add a create option if the widget needs one.
        $new_label = $this->getCreateLabel();
        if ($new_label) {
          $options['_create'] = $new_label;
        }

This vastly speeds up page loads

I agree that the page load is very slow on large taxonomies. Maybe there is a caching solution?

The use of Entity Browser might be an alternative.

I have the exact same problem... Large taxonomy vocabularies with thousends of entries. And only the normal autocomplete widget will not crack up my website. As #13 said, the normal select widget is rendering with SHS too... but it's hidden with CSS. That's wrong and causes the perfomance issues. With this technique, it's better to render the autocomplete widget too and hidden that with CSS, not the whole select list.

@Adam Clarey Could you share more details for your workaround? Because setOptions() is set in OptionSelectWidget and not in OptionsShsWidget. So where exactly did you insert the code with the caching? Thanks for helping.

Edit: The problem with caching is also, that on the first load the website is still crashing. I tried the same on the CSHS module too.

#3012825: Perfomance issues on large taxonomy vocabularies

Can anyone please share a solution/workaround for this issue?

I donnot know if this helps but there is a caching solution for Webform Simple Hierarchical Select.

https://www.drupal.org/project/webform_shs

There is also a patch

https://www.drupal.org/project/webform_shs/issues/2947933

I didn't test this yet, but a possible solution could be to remove the validation handler (the one that throws the "illegal option" error) from the field and do not load the options into the original select.
This way only the items displayed per level are loaded ...

Anyone for a patch? ;)

I ended up writing my own ajax form and block, hide the ajax autocomplete widget in the view, and fill and trigger it with js on select change.

Yes, this is a huge issue when comes to large taxonomy terms structure.
i got a 26k taxonomy and the shs select is not rendering with a internal server error 500.
The default core term field (hidden) rendered.
But empty for shs selector.

I am also in a similar situation...

Using Simple H. Select in a view as filter criteria like so :
Content: Has taxonomy terms (with depth; Simple hierarchical select) (exposed)

and loading that view takes close to 1min... right now with about 15k terms in 5 depths...
1st depth only has 12 choices... so it shouldnt take THAT long to simply load the page...

using regular hierarchical select works, but the widget is horrible for my users...

Hoping to figure out a solution :)
Have a nice day!

I am seeing the same issue. Caching the values would be a great feature. But if you have a very large taxonomy than the initial page load is still a problem.

I switched the widget from "Simple hierarchical select" to "Chosen", It cut the load time and requests in half. All values are cached. I have a large taxonomy with many levels of depth. Chosen displays the whole taxonomy and child terms just like SHS but the values are cached instead. The GUI for adding values are different than SHS.

I tried the module Client-side hierarchical select https://www.drupal.org/project/cshs. The GUI is similar to SHS. The values are now cached and the node edit form loads faster than using SHS.

@leisurman, Tried those 2 but the first cache build is killing my server resources. (my taxonomy term data too many)

I'm using STRAW https://www.drupal.org/project/straw now.
It uses cache and rebuilt the cache every time a term is created/updated regardless of different vocab. (taking huge resources as well).
So I modified the module to rebuilt cache during cron at midnight and use the same cache for the day.
The downside is the changes made to terms won't be reflected immediate on the field selection, it have to wait until the cron job execute and rebuilt the cache.

@ktch_my Thank you for your suggestion. Is there a Views-Feature available for straw? And the possiblity for a select list/dropdown?

@ktch_my. Thank you. The GUI looks as good as SHS. I will try this.

I'd try it, but that straw is D8 only... and i have way too many modules that dont have a d8 port yet...

I used bellow module
https://www.drupal.org/project/entity_reference_tree

This is also D8 only...

Anyone has any suggestion for D7 big taxonomy? I'd really like to figure out a way to be able to search through those hierarchy without taking 2mins to load the page every time... I tried pretty much every method known of caching... either it completely broke the page or it didn't work at all...

Right now I have 2 pages that uses Hierarchical Select (node edit page) and Simple Hierarchical Select (view search page) and both of them take a very long time to load up... I'm searching literally every week for the past month for about 5-10h per week to no avail...

If anyone can help out I'd be really grateful :)

EDIT 2 Years Later :
I actually found "Simple hierarchical select" and managed to make it work perfectly with Drupal7... it does not have the long loading bug with 50,000 terms mega hierarchy with 5 depths... so I will be unfollowing this issue since this is now a D8 module... just thought i'd edit my last post in case someone comes here looking for a D7 solution :)

I have solution.

This module (in the attachment) I ordered one for myself for the money. But I think it will be useful for everyone.

@sashken2 I hope you didn't pay much for the module ... it's - lets say - somehow special.
But the module gave me the right hint to add a major change to SHS so the original select element isn't loaded anymore.

I've tested using 5000 terms (max-depth 5) and the node form and the widget loads nearly instant.

10k, 3-level taxonomy was getting OOM errors when trying to load the form. 8.x-1.x version.

The source of the issue is that SHS activates on top of the core select element, which must have every term available (based on depth settings) so that the one selected via SHS can be selected on the form element that actually gets submitted.

However, the default TermSelection handler actually loads all terms in getReferenceableEntities(), in order to add the - depth indicators, and translate the term title. Since we're using SHS, the form element doesn't need all of that.

Instead, we've defined a custom EntityReferenceSelection handler specifically for the field and vocabulary we need it on, and for the options we've used a database query to provide options where the key and value are both the TID.

@akalata This is not necessary anymore if you use version 2.x.
It doesn't depend on the core select element so only the terms necessary for the current level are loaded.

@stBorchert how did you hide the original select?

In version 2.x the widget doesn't depend on the core select element anymore. See function formElement() in version 2.x vs. version 8.x-1.x.
So there is no need to hide the original select anymore and the widget is very fast.

@stBorchert But in the page the select is always hidden with all the options, I have 40K and it slows down the page a lot in rendering.

@antonio.cangemi Are you sure you are using version 2.x? That version shouldn't load the original widget.

@stBorchert Yes I have the version: '2.0.0-rc1' and I use the shs in a view as exposed filter
Content: Has taxonomy terms (with depth) (exposed) => Simple hierarchical select
The exposed filter print in page another select with class ="shs-enabled form-select form-control shs-processed hidden" with all 40k options

Oh, the views filter ... maybe I have forgotten to rewrite them :D

@stBorchert thanks, I hope you can fix the bug soon, it's a very important module.

@antonio.cangemi If it's so important, surely you don't mind writing a patch for it too, do you?

@stBorchert I'm trying but with poor results, I have recently been using Drupal 8.

A little trick to avoid printing the original select in page with all the options:

/core/modules/taxonomy/src/Plugin/views/filter/TaxonomyIndexTid.php

protected function valueForm(&$form, FormStateInterface $form_state) {
...
if ($this->options['limit']) {
$query->condition('vid', $vocabulary->id());
}
+ if ($this->options['type'] = 'shs') {
+ $query->range(0, 1);
+ }

AppView.js:
+ $(app.$el).append($('', {
+ value: value,
+ text: value
+ }));

app.$el.val(value).trigger({
type: 'change',
shsContainer: container,
shsWidgetModel: widgetModel
});
return app;

This may be of some help for the maintainers...

I'm using the SHS widget for term on a field (3k terms, one child level). It always took about 5 seconds to load. Not terrible, but I still wanted it to be more instant since the terms are offered on my registration form.

I was testing autocomplete widget to see if i could make it work for my use case (which it doesn't), however, after setting the widget back to SHS I'm no longer seeing a lag. My registration page loads instantly now.

To confirm I wasn't loading cached data I tested on 3 different browsers in "private browser" (no data stored about my site). They all loaded the page instantly.

So, I'm wondering if switching the widget released some kind of hold, residual data, in the database.

Anyway, just fyi

Same problem. Edit form for a node that contains a term reference field (some 40k terms) with SHS takes a full minute to load. If SHS is replaced by eg autocomplete widget in the form, the edit page loads instantly.

Hello,

I am facing same issue on my website. The quickest solution I was able to figure out was to empty the elements from original select and then hide it with css. The shs select is working as expected and original element is not slowing down the website.

Maybe not perfect but working solution.

Edit: After more testing I have found out that its not working properly in all cases.