Custom Module Speed

Advanced Development
1

Does using a liquid collection slow down the rendering of data in a custom module?

I have a data-intensive custom module, and I trying to speed it up. I would prefer not to use pagination just yet.

Thanks,
Shannon

2

I just did a test, and both ways took about the same amount of time.

3

Would you be able to share your code?
How are you measuring speed? is it the actual processing time of Liquid or actually the assets on the front-end loading?

4

The delay is because the custom module is actually called recursively to build a family tree. Iā€™m using an accordion menu from Foundation for the expanding and collapsing, but hereā€™s the page stripped down without Foundation or my CSS:

https://hold-jmb-family-tree-code.treepl.co/testing

Itā€™s taking about 5 seconds to load the simplified version and about 12 seconds with full design, styling, and Foundation.
Hereā€™s the page with full design: https://hold-jmb-family-tree-code.treepl.co/family-tree-1

The Custom Module item represents a family member with custom properties for name, sex, mother [which is of type datasource that points back to this very custom module - the recursive part], and father [which is also of type datasource and points back to this same custom module], and a few more descriptive fields

Hereā€™s the simplified code. It starts with a call to a detail layout specifiying the top node by id, which then calls the list layout to build the hierarchy of ancestors:

{% if this.items | size > 0 %}
    <ul >
        {% for item in this.items %}
            {% if item.name != "Unknown" %}
            <li>{{item['firstname']}} {{item.lastname}} {% if item['AlsoKnownAs'] != null %} / {{item['AlsoKnownAs']}}{% endif %} {% if item['MarriedLastNames'] != null %} / {{item['MarriedLastNames']}}{% endif %}&nbsp;&nbsp;{% if item.yearofbirth != null %}[{{item['yearofbirth']}} - {% endif %}{% if item['yearofdeath'] != null %}{{item['yearofdeath']}}{% endif %}{% if item.yearofbirth != null %}]{% endif %}

              {% if item['Sex'] | downcase == "female" and item.id != item.mother %}
                    {% component source: "Family Members", layout: "List-Testing", filterBy: "Mother", filterValue: "{{item['id']}}", limit: "99999", object: "collection", type: "module" %}
              {% elsif item.id != item.father %}
                    {% component source: "Family Members", layout: "List-Testing", filterBy: "Father", filterValue: "{{item['id']}}", limit:  "99999", object: "collection", type: "module" %}
              {% endif %}
                
            </li>
            {% endif %}
        {% endfor %}
    </ul>
{% endif %}
5

Hey thatā€™s pretty cool!

When the nested ā€œFamily Membersā€ components run they are only returning a few items each recursion arenā€™t they, so I wouldnā€™t think this should slow down all that much. So it must just be the recursion itself that is slow (not so much the amount of data).

Two main factors come to mind though which might impact the speed here:

  1. This is a trial site and so the instance might have reduced resources allocated until itā€™s a paid site???
  2. As you originally asked, being a collection may have something to do with it. Switching it to an object: "list" rendering method might make a difference???

Probably need @vlad.z input here.

The only possible optimisation I could suggest, which may or may not make any difference at all, is whether or not you need the additional condition and item.id != item.mother? Wouldnā€™t the current item ID always be different to item.mother as someone wouldnā€™t be their own mother? Maybe Iā€™m missing something thoughā€¦

6

ā€¦had another thought; where youā€™re doing {% if this.items | size > 0 %}, the ā€˜sizeā€™ method is a liquid filter which it has to calculate. So maybe try avoiding this and get the total item count directly from an existing value. Should be able to do {% if this.pagination.totalitemscount > 0 %}

Again, no idea if this is more performant but have to try every little thing when it comes to optimisation :slight_smile:

7

I added this because, of course, we had a data input error, which then caused an infinite loop. Someone entered a woman and selected herself as the mother. :slight_smile:

8

Converted the code to use ā€œobjectā€ instead of ā€œcollectionā€,
removed the test on the collection size,
but itā€™s still slow ā€¦
I also added some basic CSS to make it look like a real hierarchy :slight_smile:

9

Letā€™s hope itā€™s because itā€™s a trial site. Vlad would need to comment further on thatā€¦

10

We are currently working on a database improvement feature that will significantly increase internal search and filtering speed for any module items (like your case). Itā€™s a high priority at the moment so itā€™s expected to be realeased in one of the upcoming sprints.

2 Likes
11

That is GREAT news!!! THANKS!

12

@vlad.z, any progress with Custom Module speed? My family tree which used to take 11 seconds to load is now taking 35 seconds to load.

See my example @ https://hold-jmb-family-tree-code.treepl.co/testing

It is recursively calling the same module. I am now brainstorming pagination ideas.

Thanks,
Shannon

13

Hi @shannonlynd
We have done some optimization on overall site speed. So your custom solution with Custom Module will most likely speed up after current release update.

3 Likes