Comments (10)
That's really what I was proposing in the first solution above. I'll knock up a prototype and see if it works for now.
from automerge-repo.
This is much much too slow! About 35ms too slow. Thanks for flagging it. Why do you suspect the patchCallback would be faster?
from automerge-repo.
I have been doing some more experimenting with this and a couple of things came to light. Firstly, diff works much faster on newer documents with fewer changes. This makes sense as diff moves through all changes in the doc to create patches.
However, the patchCallback doesn't seem to take significant time at all. My understanding of this is that patches are effectively produced during each change to progress the document at the js level. They are effectively already produced, so little additional work is required. This was reflected in my tests too.
from automerge-repo.
Okay, yeah, I seem to remember @orionz warning me about this. I'd moved to explicit diffs in anticipation of wanting to support branching / shutting back and forth on the timeline. I guess I'd underestimated the cost. We should fix this.
from automerge-repo.
I'd like to get this fixed, but I could do with a little guidance.
Change events are emitted by the DocHandle
state machine, comparing the latest doc state with the previous to determine if a change has occurred. If we keep this method, then the only way i can see to get patches into the change event is to store them in the state machine. Perhaps as lastPatches
?
However, patches don't really feel like they belong in the state machine to me? The alternative would be to emit changes outside of the state machine, and only use xstate to track the internal state (loading, ready etc).
What do you think?
from automerge-repo.
Yeah patches feel like they shouldn't be part of the state machine, which is more concerned with the availability of the document. Can we have a DocHandle#lastPatches
member field?
from automerge-repo.
That almost feels as though it is still part of the state. To my mind patches only apply to the change they are emitted with
from automerge-repo.
I agree that it's awkward to hold the state on the DocHandle
, but I think this is always going to be an interim solution before we get branches done. I don't think of patches as attached to a change (assuming by "change" you mean any set of changes whether generated locally or received over the network), I think of patches as associated with a tuple of (last patched heads, current heads), this captures the fact that the patch depends on what the state was before the change.
We currently don't have to track this "last patched heads" state anywhere because the onTransition
function has access to the previous document to get the heads to diff from. To me then, adding lastPatches
somewhere is equivalent to storing the previous doc on the context
. Maybe that points to the way to implement this, as a lastPatches
on the context
of the state machine?
from automerge-repo.
Closing this out -- we've instead made the extra diff basically free.
from automerge-repo.
@pvh While I appreciate that the time has been wildly reduced since the initial report, diff is still taking ~10-15ms for me in most cases.
While not massive in the grand scheme of things, it is roughly 1/3rd of the time for a change which causes a render (the dropHandler in the flamechart) and significantly more (>70%) for the two small changes which follow.
from automerge-repo.
Related Issues (20)
- NodeFSStorageAdapter lock exception on large number of updates. HOT 2
- An unavailable document may just not be found yet
- WebSocket Ready flag should only be set after Open event HOT 2
- Get latest changes as a document instead of a binary HOT 5
- Virus detected in github head! Windows Defender Trojan:Script/Wacatac.H!ml HOT 4
- WebSocket client disconnection HOT 1
- Access to RawString through automerge-repo? HOT 1
- pnpm run dev, pnpm run dev:demo not working HOT 3
- Out of memory errors after creating enough large documents in repo HOT 7
- network sync protocol leaks documentIds to peers HOT 2
- [Svelte] Counter works but Text doesn't HOT 2
- On Peers in Automerge-Repo: Design HOT 2
- When a change event is emitted by the handle the `handle.docSync()` is still the old value HOT 5
- Large enough messages block the main thread for a long time, which can lead to socket timeouts on blocked clients HOT 3
- svelte: provide a way to await the document becoming ready HOT 1
- Repo and WebSocket provider send two responses for a "request" - the first unavailable, the second a sync HOT 1
- Share policy prevents fetching document from sync server
- repo.clone error message suggests using "handle.waitForReady", which doesn't exist
- Add a way to properly close and cleanup automerge-repo HOT 1
- Inactive `DocHandle`s are not evicted from `handleCache`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from automerge-repo.