hi there,
i use HS on a very simple vocabulary- only 10 terms. only one of the terms A (for testing) has another level of subterms (only two, A1, A2).
on editing, selecting this term A shows the second dropdown for the next level but loading its two terms takes several seconds! any idea
what could be the problem?
i have to say that this vocabulary is attached to a contenttype containing approx. 700 nodes- but the number of nodes shouldn't have any
effect, should it? i didn't turn on "show nodecount".
any help appreciated
tom

Comments

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Assigned: Unassigned » wim leers
Status: Active » Postponed (maintainer needs more info)

The number of nodes indeed shouldn't have any effect.

Do you have many modules enabled? Do you have modules enabled that affect Taxonomy DB queries (i.e. Taxonomy permissions modules)?

Finally, please enable developer mode (consult the documentation to find out how to do that), and you'll get to see how long the different rendering stages take. That'll help you track down what's going on.

thommyboy’s picture

thommyboy commented

the "read documentation" on http://drupal.org/project/hierarchical_select
doesn't tell anything about developer mode?

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

That's because it's the documentation for users, not for developers. For that, you have to look at API.txt.

thommyboy’s picture

thommyboy commented

sorry, my fault ;) i tried this on a testserver. edit a node that uses a HS with only a few terms and one term having a second level containing two terms. that is what debug says. the output starts with building the HS, then a select the term having another level (the part where the POST comes) and this seems to take 2.69s to render? what makes me wonder- after that i get constant (hundreds...) of "HIERARCHICAL SELECT 1" outputs, is that normal?
regards
tom

"Reload to activate window console"

HIERARCHICAL SELECT 1
Config diagnostics (config id: taxonomy-2): no problems found!
Calculated hierarchical select selection:
[]
Calculated dropbox selection:
[15]
Generated hierarchy in 6.723 ms:
Object lineage=[1] levels=[1] childinfo=[1]
Generated dropbox in 1.009 ms:
Object title=Zugeordnete Kanäle lineages=[1]
HIERARCHICAL SELECT 0
Config diagnostics (config id: none): no problems found!
Calculated hierarchical select selection:
["navigation:0"]
Generated hierarchy in 13.124 ms:
Object lineage=[2] levels=[2] childinfo=[2]
POST http://mysite/hierarchical_select_json
POST http://mysite/hierarchical_select_json
200 OK
2.69s jquery.js?D (Zeile 13)
HIERARCHICAL SELECT 1
Config diagnostics (config id: taxonomy-2): no problems found!
Calculated hierarchical select selection:
[]
Calculated dropbox selection:
[15]
Generated hierarchy in 6.723 ms:
Object lineage=[1] levels=[1] childinfo=[1]
Generated dropbox in 1.009 ms:
Object title=Zugeordnete Kanäle lineages=[1]
HIERARCHICAL SELECT 1
Drupal.HierarchicalSelect.state[hsid].log[lastBuildNumber] is undefined
for (var i = 0; i < Drupal.Hierarchica...id].log[lastBuildNumber].length; i++) {\n
hierarch...lect.js?D (Zeile 64)
HIERARCHICAL SELECT 1
HIERARCHICAL SELECT 1

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

Well, as you can see, the rendering of the various parts doesn't take more than about 20 ms in total. So other parts of your web site are making it slow.

How long does it take to render a normal page on your website? E.g. the frontpage?

thommyboy’s picture

thommyboy commented

i was just wondering what the

200 OK
2.69s jquery.js?D (Zeile 13)

part means- where do the 2.69s go? the site runs ok because it's cached. it has quite a lot of nodes (some thousand)
but what i don't understand is why just selecting the first dropdown of HS can take several seconds to load- any clue
what "other parts" of the site are involved then so maybe i could focus investigation?
i can imagine it's not HS causing the problems- was just wondering whether the number of nodes using the special
vocabulary could affect the performance as just loading some terms (i don't have any special taxonomy-modules
installed) shouldn't take that long- and the HS preview on taxonomy/edit runs faster than HS o node/edit...
thanks for your help
tom

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

All modules are loaded.

How many modules have you installed?

How long does it take to load node/add/page for example? And the frontpage? "runs ok" does not mean "fast".

As I've already said, about 20 ms (6 + 1 + 13) is needed for the HS AJAX callback. So the number of terms is not the issue.

thommyboy’s picture

thommyboy commented

sorry- i don't know the drupal "internals" very well- but when the node/edit page is fully loaded, just the selection of a term in the first level dropdown resulting in displaying the second level dropdown takes 3secs- there shouldn't be any modules loaded on that? adding a page tage 2secs.
any idea why performance is better in the preview compared to editing a node (same vocabulary). you might be right assuming that it is something with this special site as the HS runs smoother on another site of mine- that's why i asked wether the number of nodes could be a difference as the site use pretty much the same modules and i try to narrow the problem...

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Title: slow level load on editing » HS is slow on the node form
Status: Postponed (maintainer needs more info) » Fixed

Because all data necessary form in which the HS is present is reconstructed, and then the piece that is needed, is rendered.

On the config form, virtually no data needs to be loaded. On the node form, depending on your setup, a lot of data needs to be loaded. So it'll take roughly as long as it takes to render the node form. That also takes 2-3 seconds then.

And that is what you have to optimize.

thommyboy’s picture

thommyboy commented

ok- thanks for that info! now i can understand why it's slower on that special site as the
affected contenttyp is pretty complex and contains several nodereference-selection fields
filled by a view. didn't know the whole form needs to be reconstructed.
and thanks again for a really nice module!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

OneTwoTait’s picture

OneTwoTait commented

Seems the problem is that, on the node form, "a lot of data needs to be loaded. So it'll take roughly as long as it takes to render the node form." The "whole form needs to be reconstructed"? That seems like a major major drawback to the module and would explain why it can often not be made to be fast enough on node forms. Actually, can it ever be made fast enough on anything but the simplest forms? I would say anything over 0.3 seconds is too slow.

howie’s picture

howie commented

I had the same exact issue and struggled with it for hours -- each HS request took 3 - 5 seconds to load each element. I am using HS on a vocabulary with 50+ terms, but I've seen HS fly on vocabularies much larger. I tried the hack in #8 but it didn't work.

I was able to narrow it down to a theme issue as HS started moving quickly after switched back to the default Gardland theme. I am currently using a Zen subtheme, which has a default option to "Rebuild the theme registry on every page" (http://localhost/admin/build/themes/settings/my_theme). This is clearly useful in a development setting to avoid caching issues for your css and js. Once I disabled that option all my HS widgets elements loaded in about 0.5 seconds.

Just a minor set back while developing but it looks like everything works just fine when i'm ready for production.

Stomper’s picture

Stomper commented

I am running a Zen subtheme with the "rebuild theme registry" option disabled. On the node creation forms it still takes at least one to two seconds to render the hierarchical select.

Other possible causes for slow rendering?

thommyboy’s picture

thommyboy commented

@Stomper

#9 says HS "reconstructs" the WHOLE add/edit form. so if this form take longe to render, HS will be slow. i had an issue using a nodereference field with widget-type set to dropdown getting (hundreds of) nodes from a view which took long. setting this to autocomplete improves things.

actually- i don't really understand why selecting something in HS need to reconstruct the whole form instead of just the HS-part?

Stomper’s picture

Stomper commented

@thommy

I think I understand what you're saying. So could caching fix this issue?

thommyboy’s picture

thommyboy commented

i could imagine it might- i did change the widget from dropdown to autocomplete which improved things a lot. right now i removed HS and switched to content taxonomy and use the tree there as i need conditional fields-function for taxonomy too so that was a better choice.

Stomper’s picture

Stomper commented

@thommy

Interesting, so content taxonomy module supports conditional fields ie. display certain fields based on which taxonomy term is selected?

If so, I need that functionality. People have been searching for that functionality from the conditional fields module.

thommyboy’s picture

thommyboy commented

exactly- it's another issue than HS but I do that. select a term from one vocabulary and than depending on the selection display one of several others vocabularies. and because you can configure it to save core-terms additional to those cck-based-terms everything is fine for other modules involved

Stomper’s picture

Stomper commented

@ thommy

Sounds good, so I'm also assuming using content taxonomy, it makes it much easier to print out specific terms from related taxonomies on a custom page.tpl?

thommyboy’s picture

thommyboy commented

please contact me directly as this issue is not the place for other module's issues...

Zaiss’s picture

Zaiss commented

I'm using HS inside a very simple custom module. I wanted to use HS to show a three level hierarchy that I pull from an external database. I have around 3000 entries. I just realized that HS is very slow ?

Please find below the DEBUG Code

HIERARCHICAL SELECT 61
Config diagnostics (config id: none): no problems found!
Calculated hierarchical select selection:
[-1]
Generated hierarchy in 349.005 ms:
Object { lineage=[1], levels=[1], more...}
HIERARCHICAL SELECT 61
Config diagnostics (config id: none): no problems found!
Calculated hierarchical select selection:
[-1]
Generated hierarchy in 349.005 ms:
log: Object { lineage=[1], levels=[1], more...}

I'm interested to know If I have done something wrong ?

kind regard's