Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality. Learn more →
Crdt-benchmarks Alternatives
Similar projects and alternatives to crdt-benchmarks
-
automerge
A JSON-like data structure (a CRDT) that can be modified concurrently by different users, and merged again automatically.
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
automerge-rs
Discontinued Rust implementation of automerge [Moved to: https://github.com/automerge/automerge]
-
-
electric
Local-first sync layer for web and mobile apps. Build reactive, realtime, local-first apps directly on Postgres.
-
teletype-crdt
Discontinued String-wise sequence CRDT powering peer-to-peer collaborative editing in Teletype for Atom.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
cr-sqlite
Convergent, Replicated SQLite. Multi-writer and CRDT support for SQLite
-
peritext
A CRDT for asynchronous rich-text collaboration, where authors can work independently and then merge their changes.
-
json-joy
JSON CRDT, JSON CRDT Patch, JSON Patch+, JSON Predicate, CBOR, MessagePack, UBJSON, JSON Reactive RPC, JSON-RPC 2.0, JSON Pointer, JSON Expression, JSON Type
-
state
A Redux-based state container for local-first software, offering seamless synchronization using Automerge CRDTs. (Formerly known as 🐟 Cevitxe). (by local-first-web)
-
-
-
dokieli
:bulb: dokieli is a clientside editor for decentralised article publishing, annotations and social interactions
-
npm-registry-couchapp
Discontinued couchapp bits of registry.npmjs.org
-
-
-
-
rtc
Discontinued Real Time Collaboration for Jupyter and beyond (by jupyterlab)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
crdt-benchmarks reviews and mentions
-
JSON-joy CRDT benchmarks, 100x speed improvement over state-of-the-art
Author of Yjs here. I'm all for faster data structures. But only benchmarking one dimension looks quite fishy to me. A CRDT needs to be adequate at multiple dimensions. At least you should describe the tradeoffs in your article.
The time to insert characters is the least interesting property of a CRDT. It doesn't matter to the user whether a character is inserted within .1ms or .000000001ms. No human can type that fast.
It would be much more interesting to benchmark the time it takes to load a document containing X operations. Yjs & Yrs are pretty performant and conservative on memory here because they don't have to build an index (it's a tradeoff that we took consciously).
When benchmarking it is important to measure the right things and interpret the results somehow so that you can give recommendations when to use your algorithm / implementation. Some things can't be fast/low enough (e.g. time to load a document, time to apply updates, memory consumption, ..) other things only need to be adequate (e.g. time to insert a character into a document).
Unfortunately, a lot of academic papers set a bad trend of only measuring one dimension. Yeah, it's really easy to succeed in one dimension (e.g. memory or insertion-time) and it is very nice click-bait. But that doesn't make your CRDT a viable option in practice.
I maintain a set of benchmarks that tests multiple dimensions [1]. I'd love to receive a PR from you.
-
CRDT-richtext: Rust implementation of Peritext and Fugue
Diamond types author here! Congratulations on getting your crdt working! It’s lovely to see a new generation of CRDTs which have decent performance.
And nice stuff implementing peritext! I’d love to do the same in diamond types at some point. You beat me to it!
Im building a little repository of real world collaborative editing traces to use when benchmarking, comparing and optimising text based CRDTs[1]. The automerge-perf editing trace isn’t enough on its own. And we’re increasingly converging on a format for multi user concurrent editing traces too[2]. It’d be great to add some rich text editing traces in the mix if you’re interested in recording something, so we can also compare how peritext performs in different systems.
Anyway, welcome to the community! Love to have more implementations around!
-
Cloudant/IBM back off from FoundationDB based CouchDB rewrite
So yes, a particularly large document is not the norm but it can happen.
JavaScript CRDTs can be quite performant, see the Yjs benchmarks: https://github.com/dmonad/crdt-benchmarks
- Automerge: A JSON-like data structure (a CRDT) that can be modified concurrently
- Automerge: a new foundation for collaboration software [video]
- Show HN: SyncedStore CRDT – build multiplayer collaborative apps for React / Vue
-
5000x Faster CRDTs: An Adventure in Optimization
Cool! It'd be interesting to see those CRDT implementations added to Kevin Jahns' CRDT Benchmarks page[1]. The LogootSplit paper looks interesting. It looks like xray is abandoned, and I'm not sure about teletype. Though teletype's CRDT looks to be entirely implemented in javascript[2]? If the authors are around I'd love to see some benchmarks so we can compare approaches and learn what actually works well.
And I'm not surprised these techniques have been invented before. Realising a tree is an appropriate data structure here is a pretty obvious step if you have a mind for data structures.
To name it, I often find myself feeling defensive when people read my work and respond with a bunch of links to academic papers. Its probably totally unfair and a complete projection from my side, but I hear a voice in my head reword your comment to instead say something awful like: "Cool, but everything you did was done before. Even if they didn't make any of their work practical, usable or good they still published first and you obviously didn't do a good enough literature review if you didn't know that." And I feel an unfair defensiveness arise in me as a result that wants to find excuses to dismiss the work, even if the work might be otherwise interesting.
Its hard to compare their benchmark results because they used synthetic randomized editing traces, which always have different performance profiles than real edits for this stuff. Their own university gathered some great real world data in an earlier study. It would have been much more instructive if that data set was used here. At a glance their RAM usage looks to be about 2 orders of magnitude worse than diamond-types or yjs. And their CPU usage... ?? I can't tell because they have no tables of results. Just some hard to read charts with log scales, so you can't even really eyeball the figures. So its really hard to tell if their work ends up performance-competitive without spending a couple days getting their enterprise style java code running with a better data set. Do you think thats worth doing?
-
A note from our sponsor - InfluxDB
www.influxdata.com | 28 Mar 2024
Stats
dmonad/crdt-benchmarks is an open source project licensed under GNU General Public License v3.0 or later which is an OSI approved license.
The primary programming language of crdt-benchmarks is JavaScript.