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

Atomic composition implementations #289

Draft
wants to merge 2 commits into
base: preview
Choose a base branch
from
Draft

Conversation

towerofnix
Copy link
Member

Experimental! This replaces certain compositions with "atomic" implementations, which means they themselves aren't compositions at all, serving as a complete property descriptor instead. The atomic implementations are strictly in terms of a reference implementation, that being the existing composition which the atomic implementation stands in for.

Notes:

  • This may or may not provide any significant performance improvement, and since this is purely a perf pull request, that improvement needs to be established.
  • This doesn't replace dynamic caching of individual composition steps (or compositions as a whole), but that's a to-do for another time. This is generally a higher level optimization because it bypasses 100% of the composition overhead and can fully stand in for a complete property descriptor.
  • This completely bypasses both static and dynamic validation checks, which is a big downside, especially if we want to try making atomic compositional steps ({flags: {compose: true}}).
  • Also required for compositional steps is making sure that the .outputs({}) system (for renaming outputs) continues to work as intended! We're thinking the neatest way to handle both this point and the one above is basically to factor out the useful behaviors of both templateCompositeFrom and compositeFrom, and employ those in a lighter-weight wrapper - one which always only expects a single compute/transform. However, this needs to be compared - in terms of performance - against just using the existing templateCompositeFrom and creating single-step compositions, which are perfectly well supported already.
    • Likewise, if single-step composition templates are basically as performant as an unwrapped atomic implementation (and both of those are substantially faster than the compositional implementation in the first place), then the existing atomic implementations should be redefined as single-step templates, so they can benefit from the same static conveniences (mostly input validation) as other composition templates.

@towerofnix towerofnix force-pushed the preview branch 3 times, most recently from 87c7bd7 to dcb5206 Compare June 19, 2024 01:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant