Clojurians Log v2
pathom
As I understand p.eql/process in it’s output is silent about Exceptions. thrown in resolvers?
Is checking the meta data, the recommended way of checking for errors atm? E.g.
(-> process-result
(meta)
::pcr/run-stats
::pcr/node-run-stats
::pcr/nodes-with-error)
check the attribute errors plugin: https://pathom3.wsscode.com/docs/built-in-plugins#attribute-errors
Ah nice, thanks! I’ve read through the debugging page but I didn’t get to plug-ins!
@wilkerlucio I have to say though, Pathom 3 seems really snappy. We wrapped all resolvers in Honeycomb logs, and played around with the different parsers/resolvers in Pathom 2, along with batching. Then we threw Pathom 3 into the mix (and immediately got problems due to the well-known batching problem) Bottom line, Pathom 3 without parallelism or batching is just as performant for our particular use case as Pathom 2 with parallelism, batching, & tweaks, if not better. So many kudos on the great work, but also, why is this so? 😄 Does Pathom 3 produce more clever plans?
From where I'm sitting, it certainly looks like Pathom 3 is calling the resolvers fewer times than Pathom 2 did, which might account for the performance: it seems to be doing less work. This seems to be the case even though you recently turned off some optimizations, from what it sounds like. I also noticed that I could severely suboptimize Pathom using batching. I don't remember if this was Pathom 2 or 3, but when I turned on batching it seems like it ended up calling more resolvers (though, in parallell, due to how I implemented the batching). From this it seems like it really isn't worth batching too aggressively, unless you know that the resolver is going to quite expensive to run per individual call.
Yeah, I've noticed that it's hard to get any I/O to Datomic faster with batching, since it's not really "I/O", and Datomic caches aggressively.
hello Henrik! glad to hear about these benchmarks, you make my day happier 🙂 about how, its because Pathom 3 goes much more strait to the point than Pathom 2. Pathom 2 still follows the same parser/readers abstraction that were created by David Nolen in the first versions of Om.next. by that time, connect ideas were inexistent. later when I got to the connect idea on Pathom 2, it was an addition to it, so it has to accomodate itself there. in Pathom 3, instead of connect having to “go around” the readers interface, connect is the main thing in Pathom 3, and anything else needs to go around that. This allows me to optimize in such a way that wouldn’t be possible in Pathom 2 the new planner thing also helps, Pathom 2 keeps planning (and in case of errors, replanning) all the time while it runs. Pathom 3 model plans once per entity, and that thing is cached, so all the traversing code to figure things out can be isolated, and by the time Pathom 3 is “running”, it can just go traversing the plan nodes, never needs to replan And most important, I started Pathom 3 with the previous experience about what was bad about Pathom 2, that surely helps me avoid some pitfalls
@wilkerlucio I have a progress on windows build / release process of pathom-viz with github actions. stay tuned for PR.
trick is, you have to use shell: powershell and once you're down this rabbit hole you have to have two run builds. One for MacOS and Linux, and separate one for Windows.
ifs are ugly, but since the matrix is small its probably acceptable.
merged, I’m doing a few design adjusts in the Requests tab
them I’ll make a tag so we get the windows release on the main repo 🙂
🤞
:hand_with_index_and_middle_fingers_crossed: https://github.com/wilkerlucio/pathom-viz/runs/2414822943?check_suite_focus=true
👏 🎯
Congratulation sir! Your application runs on one more platform 🙂
without requiring the user to compile itself 🙂
I’m updating the docs in Pathom 3 as well, and making the announcement text, will be up in a min
as I promised to you once. I added Pathom-viz to scoop bucket and it can now be installed with scoop installer from the command line.