Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[5.x] Augmentation performance improvements #9636

Merged
merged 45 commits into from
May 2, 2024
Merged

[5.x] Augmentation performance improvements #9636

merged 45 commits into from
May 2, 2024

Conversation

JohnathonKoster
Copy link
Contributor

@JohnathonKoster JohnathonKoster commented Mar 2, 2024

This PR is an extension of #9574, and reworks some more internal augmentation behaviors. The changes in this PR come together to allow us to reuse fields arrays and augmentation keys as much as possible in a new BulkAugmentor. This new class will work to reduce the overhead of resolving this information as much as possible. For example, if you want to augment 1,000 entries and they can all safely reuse the same fields/keys, the BulkAugmentor will only do those calls once. This PR only focuses on pages/entries for now.

  • Delay execution of "normal" Value objects
  • If a user calls get directly, they shouldn't need to care about materialization
  • Introduce Transient values - these will be passed around until something actually needs a value. This makes InvokableValue and DeferredValue even more lazy 🥳
  • Rework some shared logic across deferred values
  • Rework augmentation selection to support passing in a known list of fields
  • Add support for "bulk augmentation". Augmentor 50000 ™️
    • Augmentable items need a way to tell us "what" they are in general terms. i.e., Page/entry for collection.posts.blueprint_a, or page/entry for collection.posts.blueprint_b
  • Rework nav tag tree builder to bulk augment
  • Rework collection tag to use transient values will just handle this Antlers-side to cause less chaos
  • Rework internal Antlers variable logic to use transient values
  • Rework dump tag and modifier to resolve transient/deferred values

@JohnathonKoster JohnathonKoster marked this pull request as draft March 2, 2024 16:02
@JohnathonKoster JohnathonKoster changed the title [5.x] Deferred all augmentation [5.x] Defer all augmentation, allow for Bulk Augmentation (reuse key/fields across similar items), even more internal augmentation adjustments Mar 2, 2024
* Allow for implementors to return `null`, which disables the bulk process for that item
* Entry now takes data keys into consideration to prevent "locking" an entry into something if it has custom data
@JohnathonKoster JohnathonKoster mentioned this pull request Mar 2, 2024
37 tasks
@JohnathonKoster JohnathonKoster marked this pull request as ready for review March 2, 2024 21:25
Copy link
Member

@jasonvarga jasonvarga left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please target master.

@JohnathonKoster JohnathonKoster changed the base branch from 4.x to master March 8, 2024 01:07
@jasonvarga jasonvarga dismissed their stale review March 11, 2024 16:55

Requested changes were made.

jasonvarga and others added 6 commits March 12, 2024 12:37
…some just because ...

- Dedicated AbstractAugmented 'wrap' methods, to avoid passing around hard to follow booleans.
- Avoid a hard to follow boolean in InvokableValue
- Make InvokableValue easier to follow both paths in general.
- TransientValue and DeferredValue now pass their references when calling shallow(), which were missing, and was the reason for needing to check for nulls.
- Typehints and visibility
… ...

If you pass a closure as the raw value, it'll lazily evaluate them when resolving.
materialize() just called resolve() and returned a new Value instance.

Now that the subclasses are gone, there's no need to new up a separate Value instance. It can just return itself. With that gone, we might as well just call resolve since materialize would just be an alias.
@jasonvarga jasonvarga changed the title [5.x] Defer all augmentation, allow for Bulk Augmentation (reuse key/fields across similar items), even more internal augmentation adjustments [5.x] Augmentation performance improvements May 1, 2024
- Add static factory methods to BulkAugmentor.
- Rename BulkAugmentor augmented() to toArray(). Seemed more inline with what it did. Looks like it makes sense when compared to the toDeferredAugmentedArray in the "else" where its used in RuntimeValues.
- Reduce visibility where possible
Since dd(), dump(), etc can have variable arguments, avoid making our own Dumper methods. Just use the class to resolve the values and pass them into the original functions.

Rename resolveValues to resolve.
Simplify map.
Remove unnecessary guard.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

2 participants