This PR seeks to fix a bug that causes individual family kinetics pages to load extremely slowly.
Requests to all kinetics sites are handled in the kinetics function. The code attempts to generate a KineticsDatabase object depending on the subsection of kinetics (e.g. groups, training, rules, if present) and family name (if present).
If no valid KineticsDatabase object is found (such as when the subsection is not able to be parsed get_kinetics_database e.g. does not fall under groups or training, etc) then the website attempts to render the "list view" [See https://rmg.mit.edu/database/kinetics/families/ for the "list view" of all families]. It is possible to specify the family name as the subsection, which results in loading the list view only for that family.
In the current implementation of loading the "list view", the entire database is loaded and processed regardless of whether you are listing all families or 1 family. Processing families is expensive because the function getUntrainedReactions scales with depository size & number.
The proposed change seeks to fix this by only processing the family being queried when "list view" is called.
This PR seeks to fix a bug that causes individual family kinetics pages to load extremely slowly.
Requests to all kinetics sites are handled in the
kineticsfunction. The code attempts to generate a KineticsDatabase object depending on the subsection of kinetics (e.g.groups,training,rules, if present) and family name (if present). If no valid KineticsDatabase object is found (such as when the subsection is not able to be parsedget_kinetics_databasee.g. does not fall undergroupsortraining, etc) then the website attempts to render the "list view" [See https://rmg.mit.edu/database/kinetics/families/ for the "list view" of all families]. It is possible to specify the family name as the subsection, which results in loading the list view only for that family.In the current implementation of loading the "list view", the entire database is loaded and processed regardless of whether you are listing all families or 1 family. Processing families is expensive because the function
getUntrainedReactionsscales with depository size & number. The proposed change seeks to fix this by only processing the family being queried when "list view" is called.Examples: Small family - Current site (slow) vs. fixed site (fast) Big family - Current site (slow) vs. fixed site (fast)