I have a big term reference tree in a form (1000+ states, regions, districts, towns,...). It's quite slow, of course. But I found two ways to reduce a lot the server-side load:
- Avoid loading of terms when locale is activated but only need the term name.
- To get term children, do one select query to get the whole vocabulary hierarchy once and use array_keys() to filter it for each term, instead of doing one new select query for each term.
This reduces a lot my loading time (for example XHProf tells me that _term_reference_tree_get_children() takes 4 times less time to run).
Code attached.
Comments
Comment #1
dave reidThis needs to be re-rolled for the current changes.
Comment #2
xadag commentedYes it will be great to have this patch work with the latest version of term tree, in dev branch.
Because with large amount, this widget doesn't work as expected.
Comment #3
blazindrop commentedI can work on re-rolling this. We need this improvement as well and already did some work in this area. I may have some extra caching since terms aren't likely to be updated often. We can then leverage taxonomy_term_presave() to expire that cache. Will hopefully post a patch in the next few days.
Comment #4
blazindrop commentedI rerolled the original patch here and did some testing. At least on my machine, the results are not an improvement over stock 1.10 term reference tree. Before I came across this issue I started some performance improvements going down a different path. I highlight those results below also relative to the original patch and stock 1.10 term reference tree.
My testing environement stats:
* Ubuntu 12.10 VM with 8G Ram, 6 CPUs
* Dell M6600 with 16G RAM alllocated to a windows 7 host
* # of nodes - 45,000
* # of terms in first vocab - 82
* # of terms in second vocab - 725
* # of term levels - 3
Using siege (siege -r 10 -c 2 -b 2 http://drupal.localhost/node/add/article) against our article node add page having about 12 fields. Two of those fields use term reference tree for two vocabularies.
The test results:
Stock 1.9 Term reference tree: test run #1 = 1.97s, test run #2 = 2.0s, test run #3 = 2.0s
Stock 1.10 Term reference tree: test run #1 = 2.04s, test run #2 = 2.1s, test run #3 = 2.03s
Stock 1.10 with term_reference_tree_performance_improvements.patch (original patch): test run #1 = 6.13s, test run #2 = 5.88s, test run #3 = 5.88s
Stock 1.10 with my performance patch: test run #1 = 1.53s, test run #2 = 1.48s, test run #3 = 1.49s.
So roughly a 25% performance improvement over stock 1.10. I would love if someone else validated my results, especially for the original patch on this ticket. Is it possible there's a chance from 1.9 to 1.10 that would make this a performance degradation?
My approach is to cache the output of _term_reference_tree_get_term_hierarchy() for 15 minutes by wrapping it in another function. If a term or vocabulary should change the cache for that item is expired. I tested the cache expiration by changing terms and vocabularies and it works as expected.
Comment #5
blazindrop commentedFigured out how to attached a patch and have test bot ignore it :)
Comment #6
aedwards88 commentedI have tested this patch, however I did not see any improvement in speed when dealing with large number of taxonomy terms. When using Term Reference Tree widget it takes quite some time to load, as well as select all items when selecting a parent term.
Comment #7
blazindrop commentedaedwards88 - can you give some more details on your test environment? Some questions:
* How many terms did you have?
* How many levels of terms (e.g. depth) in your taxonomy?
* Also, just to confirm you tested the term_reference_tree-cache_tree-1966370-4.patch patch?
The one thing I'm wondering is if you are using memcache. If not, your cache_set() will write to the database, which will slow things down. It would be nice to see some before/after test results using something like siege. Make sure you have page caching disabled so you're not testing cached page retrievals! :)
Comment #8
aedwards88 commented-There are roughly over 5000 terms within a taxonomy term tree.
-The level of depth is 3 levels.
-Yes, however I could not test via Simplytest.me. A error occurs upon testing and applying the patch on Simplytest.me
Comment #9
aedwards88 commentedI also believe this should pass Drupal's automated QA before actually using this. From the way it looks at this moment it seems the test has been postponed.
Comment #10
aedwards88 commentedTesting this results in failure. Testing should pass Drupal.org quality assurance.
Comment #11
bernardopaulino commentedCould not find any improvements when loading terms. Currently I have a vocabulary containing about 2000 terms with more than 4 levels. In my scenario I want to select terms on the user's edit page and it takes more or less 17 seconds even with the patch. I don't know if we can use cache for authenticated users.
I've tried using some other modules like hierarchical_select but doesn't use the same kind of widget and I don't really like it. But at least works better than the this widget because it loads terms while I am selecting (if you know what I mean).
Comment #12
metammar commentedtaxonomy tree view cant load large taxonomies and should use technologies like ajax... we also have many problems in loading large taxonomies!
Comment #13
metammar commentedIf anyone has problem with loading many terms.. can use this patch:
https://www.drupal.org/node/1148418
We used it and all of our problems solved! hope to merge in last release of module..
Comment #14
gaëlgComment #15
vladimirausThank you everyone for your contribution.
Drupal 7 is no longer supported but we always need support for Drupal 11 version.
Closing as outdated.