Support

Account

Home Forums Add-ons Repeater Field How to improve performance on add_row() for repeater field

Solved

How to improve performance on add_row() for repeater field

    • alex-er

    • February 12, 2020 at 5:12 am

    I’m adding rows to a repeater field through add_row().
    It takes about 7 to 8 seconds to add about 100 rows. The probleme is that, sometimes, I can have more than 1000 rows to add at once…
    Is there a way to improve this? With something like a single add_rows() function that would add all records at once?
    The code itself is very simple (see below) so it is all being spent on the add_row() function itself:

    foreach ($new_records as $each_new) {
        $new = array(
            'a' => $each_new[1],
            'b' => $each_new[2],
            'c' => (isset($each_new[3])) ? $each_new[3] : '' ,
            'd' => (isset($each_new[4])) ? $each_new[4] : '' ,
            'e' => (isset($each_new[5])) ? $each_new[5] : '' ,
            'f' => (isset($each_new[6])) ? $each_new[6] : ''
        );
        if (add_row('custom', $new, $each_new[0])) {
            $add_count++;
        } else {
            $add_error++;
        }
    }

    Thanks,
    Alex

  • There isn’t going to be a way to improve performance. The issue is that even if you update the entire repeater at once of you update 1 row at a time you will be generating more than one DB query for each sub field of each row being added. 1000 rows * 6 sub fields = ~12,000 db queries.

    If it’s not too late you should reevaluate why you are using a repeater and if there might be a better way to accomplish the storage of this data.

    • alex-er

    • February 13, 2020 at 8:17 am

    Thank you John for your comments.

    Yes, there might be other ways to accomplish this but repeater is the natural one here.

    What makes me believe that there might be something else at play is the fact that the time it takes to process the add_row() function increases exponentially as the number of iterations grow (and the same is true for delete_row() ).

    I ran some tests with 150, 300, 500, 700 and 1000 iterations (for each quantity I ran it at least 3 times and this is the average). I’ve placed timers just before and just after the add_row and delete_row loop, just to be sure nothing else was impacting them. Here are the results I got:

    150 – add_row: 15s (100ms per record) – delete_row: 10s (067ms per record)
    300 – add_row: 45s (150ms per record) – delete_row: 36s (120ms per record)
    500 – add_row: 1m52s (230ms per record) – delete_row: 1m30s (180ms per record)
    700 – add_row: 3m13s (276ms per record) – delete_row: 2m52s (245ms per record)
    1000 – add_row: 7m32s (452ms per record) – delete_row: 6m24s (385ms per record)

    The numbers themselves are not important (the time will depend on many variables, including server setup, connection, etc). But the fact that the time per record grows exponentially is what confuses me.

    I was just hoping that someone would tell me that this is either the normal behaviour for ACF’s add_row and delete_row or that I’m missing something (like a flag or another function or parameter)…

  • Those are interesting numbers. Going to tell you that I don’ use add_row() and delete_row(). I’ve only every created a repeater that has a couple hundred entries once.

    Most of the time when I’m updating a repeater I update the entire repeater using update_field(). Basically I generate all the rows of the repeater.

    
    $repeater = array(
      // each nested array is a row
      array (
        // each row is made up of field_key value pairs
        'field_XXXXXXX' => 'field value',
        'field_YYYYYYY' => 'field value
      )
    );
    

    once the repeater and all rows are created I call update field on the repeater

    
    update_field('field_ZZZZZZZ', $repeater, $post_id);
    

    Not sure if this is something you can try or not.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.

We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Cookie Policy. If you continue to use this site, you consent to our use of cookies.