⚡ Optimize site header rendering performance by removing O(N^2) loop - #52
Conversation
Eliminates O(N^2) complexity when rendering the site header for users not explicitly using `site.header_pages`. When `site.header_pages` is set, the custom sorting order is still respected. Otherwise, the code iterates over `site.pages` directly, avoiding costly repetitive lookups with the `where` filter. Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
💡 What:$O(N)$ time instead of performing nested filter lookups.
Optimized the header iteration logic in
_includes/header.html. Whensite.header_pagesis customized by the user, the current logic is maintained to preserve their requested sort order. However, when the user does not specify a custom ordering (the default case), the rendering now directly loops oversite.pagesin🎯 Why:$O(N^2)$ search to render header items by checking every single page path against the total list of pages using the
The previous implementation performed an
wherefilter. For sites with a large number of pages, this became a significant bottleneck that scaled poorly during site generation.📊 Measured Improvement:
Using a standalone benchmark that mimics 1000 pages during a Liquid template render:
This establishes a vastly improved performance baseline without changing any expected visual output or feature functionality.
PR created automatically by Jules for task 1024694233583332932 started by @hodovani