Better tree handling

[grantfitzsimmons]

When curating a tree (such as the Taxon tree) the speed at which it reloads and how long it goes on for makes it difficult to do a lot of tasks in one session.

Reported By: RBGE

[grantfitzsimmons]

Several collection managers have reported that it takes a long time for Taxon tree operations to complete when doing their revisions. In S6 they have to run tree-edits after-hours because they take a long time and they block other users from logging in while it is running. Users that are logged in at the time the tree operation begins are able to continue working in Specify.

In S7, we have found that it "appears" that taxon tree edits go super fast, but then this past week a CM was cleaning up the taxon tree in S7 and because each edit she did seemed to go quickly, she went forward and did about 5 back to back. It was ratified by other CMs that it seems that S7 can only handle about 4 edits within a close time span of eachother and that in fact, S7 is actually NOT DONE with the revision despite giving that impression and that it is actually working in the background to complete the tree edit. Our S7 app then becomes unresponsive when we cross this threshold and the only way to recover is to wait a long time for the database queue to resolve or to manually flush the queue.

Reported By: Matthew at The University of Michigan

[grantfitzsimmons]

NHMDenmark/DanSpecify#198

Could we investigate the speed of Specify and anything that could be done to improve it. @justin-wynns has been monitoring things and here are some examples from the last week:

26-10-22

• 17:45. Catalog no. 000716190. Wanted to change 'Taxon' "Matricaria maritima" to "Matricaria ambigua". Replaced "maritima" with "ambigua". 15 seconds "Loading" before the indexed option appears.
• 17:53. Adding new det. "Matricaria ambigua" takes 12 sec. for indexed option to appear.
• 18:22. Same, but only typing "Matricaria" calls up an inappropriate index after 15 seconds.

31-10-22

• 09:28. Catalog no. 000724245. Changing subspecific taxon name "(Ait.) Hult." to " "decumbens" and adding authorities. Save takes 59 seconds to take effect.
• 09:59. Catalog no. 000779726. Changing specific epithet from "alpina" to "alpinus" takes 63 seconds to take effect.
• 10:10. When attempting to merge duplicate names "Juncus alpinus" (merging one with eight child nodes and no CO records into one with eight records and no child nodes) still "Loading" after 10 minutes! Eventually results in a timeout error, but by 11:25 merge has taken effect.
• 13:43. Catalog no. 000779742. Changing subspecific taxon name "subsp. (Hartm.) Hyl." to "var. alpestris (Hartm.) Almq." Save takes 60 seconds to take effect.

01-11-22

• 11:43. Searching Taxon tree for "Pinguicula" takes 25 seconds for indexed option to appear.
• 13:35. On the Taxon tree, under Juncus arcticus, changing subspecific taxon name "Willd." to "balticus" and adding authorities. Save takes 75 seconds to take effect.
• 14:42. Catalog no. 000682801. Adding new Taxon (additional det.) Juncus arcticus × filiformis takes 73 seconds to take effect.

03-11-22

• 18:51. Takes more than 15 minutes to merge duplicates of Platanthera hyperborea.

[grantfitzsimmons]

This is something that has been reported by many institutions. RBGE has proposed just dropping node numbering in 7 as a preference (#2393)

[FedorSteeman]

Dropping node numbering would certainly help! For botany we imported an entire taxonomic spine based on authoritative sources that is up to almost 1.2 million nodes. Merging duplicates can sometimes take up to a full quarter of an hour!!!

[maxpatiiuk]

Disabling node numbering possibly won't be necessary once #3175 is implemented if the performance improvement from that is sufficiently large

[maxpatiiuk]

From @grantfitzsimmons:

Tree changes are extraordinarily slow in Specify 7 when synonymizing or merging nodes.

RBGE does not use Specify 6, but they are waiting for long periods of time to perform simple tree actions. Being able to break compatibility with Specify 6 on an opt-in basis would give greater flexibility.

Requested By: RBGE