can you please try ::pcp/experimental-branch-optimizations true in your env see if there is any difference?

It does make a huge difference !

You can see with and without the optimizations

awesome! please let me know if you find any issues using it

@U01SBSXRRH6 What is the shape of taxon-requests here? Why is it doing it twice?

@U3XCG2GBZ its actually normal on this case, but the experimental optimizations were able to handle, which shows in the image with the green nodes

@U066U8JQJ Sorry for the confusion, I don’t fully understand what is happening here and I’m just trying to figure it out. I’m not suggesting anything is wrong. Specifically I’m trying to figure out what has caused Pathom to plan executing taxon-requests twice in the first place. Typically I would think of batch resolvers or optional inputs but it doesn’t appear to be the case here.

but first time I tried to release this optimization it broke some cases to some users, I fixed it but decided to keep it as an optional experimental feature

which you can enable with the flag I mentioned here

it can be cause due to different attributes coming from the same resolver, this is more aparent when using dynamic resolvers

Ah ok. Got it now.

[{::pco/op-name 'a
  ::pco/input   [:c]
  ::pco/output  [:a]}
 {::pco/op-name 'b
  ::pco/input   [:c]
  ::pco/output  [:b]}
 {::pco/op-name 'c
  ::pco/input   [:d :e]
  ::pco/output  [:c]}
 {::pco/op-name 'd
  ::pco/output  [:d]}
 {::pco/op-name 'e
  ::pco/output  [:e]}]

yup, and with the plan snapshots you can see the compression of nodes happening

@U066U8JQJ I have a pretty crazy graph and all my tests still pass after enabling experimental-branch-optimizations

nice, good to hear, I just build more confidence to enable those by default, your input is good one on the positive for it :)

Can this be optimize ? The call to taxon-requests are merged ( when using ::pcp/experimental-branch-optimizations true ) but if I have an attribute coming from another resolver, in this case from taxon-flora-requests, then it doesn't get merged to be passed to the dynamic resolver (legacy-resolve-transaction)

one way to solve that is to create a merging resolver that take attributes from all request producing revolvers.

Actually that's not solving anything, both request producing resolver are called no matter what now, so it's just making the graph pretty.

hello @U01SBSXRRH6, not sure if I get the last case, seems with the merge thing you mention things do clean simpler

Yes but the merge resolver will trigger every resolver that it's merging so it's not a great solution.

https://clojurians.slack.com/files/U01SBSXRRH6/F04NWAA6LVB/image.png This is the most basic example, even with ::pcp/experimental-branch-optimizations true it will call the dynamic res twice.

thanks, can you make a repro for this case? I have this initial idea in mind, that sibling branches with same run-next might be able to merge, gotta explore a bit