Would there be any performance advantage to the “substract min from list” example when written with the inverse operator?
Looks like it avoids writing another loop explicitly, but it will still go through the list twice in practice. Kind of like a defer operator, but more powerful in its semantics?
The version with the inverse operator takes 948 interactions, whilst a version without it takes 1069 interactions, so there is a performance advantage.
For a list with 10000 elements the difference in the number of reduction between the two examples very closely matches 3/2, which is exactly the theoretical limit, if I analyzed the algorithm correctly.
Note that this just counts interactions, and there is a difference of parallelism between the two examples, the more optimal is actually less parallel, so the difference in time is not 3/2.
I guess the second iteration can be made parallel, as you mention in another comment. But at the cost of O(n) space to keep references to all values needing substraction?
Happy to see vc-jj.el mentioned! We just made an organization for it on codeberg and will work on getting it into gnu elpa next. It’s not feature-complete yet, but happy to get feature requests etc, https://codeberg.org/emacs-jj-vc/vc-jj.el
I was talking about what I’d need in an editor plugin: give me the magit collapsible diff UI, plus two or three shortcuts to common operations (like new, describe or commit), and I’ll be happy!
gg is not as rich as magit, and of course isn’t integrated into the editor. But it demonstrates the power of the simpler model of jj, because it’s like 70% of what you need even though it doesn’t have a ton of functions.
It could use better docs/tutorials, because it can do some very useful things that are not very discoverable (basically, drag and drop is pretty magical). If it had a jj split view it would be in a good spot — almost no need for the CLI anymore.
I used to do a lot in GitX and gg is almost to that point now.
gg looks nice, although it hasn’t been updated in a few months now, so it’s a bit behind the latest jj releases. But it doesn’t really fit the magit use case; I’m sure there’s a public for these standalone GUIs, similar to GitKraken and others for git, but they’re not for me, I really need something integrated into my editor.
Author here, happy to answer any questions.
Would there be any performance advantage to the “substract min from list” example when written with the inverse operator?
Looks like it avoids writing another loop explicitly, but it will still go through the list twice in practice. Kind of like a
deferoperator, but more powerful in its semantics?The version with the inverse operator takes
948interactions, whilst a version without it takes1069interactions, so there is a performance advantage.For a list with 10000 elements the difference in the number of reduction between the two examples very closely matches 3/2, which is exactly the theoretical limit, if I analyzed the algorithm correctly.
Note that this just counts interactions, and there is a difference of parallelism between the two examples, the more optimal is actually less parallel, so the difference in time is not 3/2.
I guess the second iteration can be made parallel, as you mention in another comment. But at the cost of O(n) space to keep references to all values needing substraction?
Thanks for writing this comparison! I am looking forward to getting a magit-like interface to jj. How well does gg compare?
+1. I’m keen on the idea of jj, but am too comfortable with magit.
I might only need 5-10% of what magit can do: collapseable diff and interactive staging.
Yeah I’ve been running jj split in a separate terminal window but magit staging for n-level splits would be great
Yes, I’d also settle for that (plus some commands to create a new change when i’m done, and maybe describe them)
I’ve wanted to play around with https://github.com/caldwell/commit-patch?tab=readme-ov-file#commit-patch-bufferel for a while, which abstracts “commit this hunk” using vc-diff and diff-mode.
Maybe that could work with vc-jj.el, easier to write than a whole new UI.
Happy to see vc-jj.el mentioned! We just made an organization for it on codeberg and will work on getting it into gnu elpa next. It’s not feature-complete yet, but happy to get feature requests etc, https://codeberg.org/emacs-jj-vc/vc-jj.el
Your parenthetical wish sounds like either
jj new -m <description>orjj commit -m <description>, I’m not sure which.I was talking about what I’d need in an editor plugin: give me the magit collapsible diff UI, plus two or three shortcuts to common operations (like
new,describeorcommit), and I’ll be happy!gg is not as rich as magit, and of course isn’t integrated into the editor. But it demonstrates the power of the simpler model of jj, because it’s like 70% of what you need even though it doesn’t have a ton of functions.
It could use better docs/tutorials, because it can do some very useful things that are not very discoverable (basically, drag and drop is pretty magical). If it had a
jj splitview it would be in a good spot — almost no need for the CLI anymore.I used to do a lot in GitX and gg is almost to that point now.
gg looks nice, although it hasn’t been updated in a few months now, so it’s a bit behind the latest jj releases. But it doesn’t really fit the magit use case; I’m sure there’s a public for these standalone GUIs, similar to GitKraken and others for git, but they’re not for me, I really need something integrated into my editor.