더 빠른 CRDT를 위해 최적화 하기
(josephg.com)- 기존 CRDT 라이브러리들의 문제점을 찾고 해결해서 더 빠르게 만드는 과정을 설명한 글
ㅤ→ 테스트 벤치마크 : 18만자 입력, 7만자 삭제, 10만번 커서 이동
ㅤ→ Automerge 대비 5000x 빠름 (5분 vs. 56ms)
- Automerge가 느린 이유는?
ㅤ→ 문서가 커질수록 내부의 트리기반 데이터 구조가 커지고 느려짐
ㅤ→ ImmutableJS를 많이 사용하는데, 기능은 좋지만 느리고 메모리 사용량이 많음
ㅤ→ 입력된 글자 각각을 별도의 아이템으로 처리
ㅤ→ Automerge는 현재 성능을 개선한 Rust 버전을 별도로 구현중
- Yjs 라이브러리는 Automerge 보다는 훨씬 빠름
ㅤ→ 데이터 구조를 개선
- Diamond Types : Rust 기반의 CRDT 구현체
ㅤ→ Rust로 언어를 변경하고 Yjs처럼 데이터 구조를 개선해서 더 빠르게 만듬
ㅤ→ 링크드 리스트 대신, Range Tree를 이용
ㅤ→ Wasm 으로 실행시에 JS에서의 스트링 변경보다 3배 빠름 (0.19s, Automerge 보다 1500배)
ㅤ→ Rust Native 로 실행시 0.056s 로 5000배 빠름
부록 A - 내 앱에서 CRDT를 써야 한다면 뭘 쓰면 좋을까 ?
- 문서 기반 협업 도구를 만든다면 "Yjs를 추천". 성능좋고 메모리 사용량 적음. 더 빨라질 예정
- 물론 Automerge도 훌륭. 아마도 올해 더 빨라질 것
- Diamond는 정말 빠르지만, 아직 기능을 많이 추가해야 함
- 문서 시맨틱 보다 DB 시맨틱을 원하면, OT 기반이지만 ShareDB를 추천
- Redwood를 기대 중
이 글은 아래 글의 저자인 구글 Wave 개발자 Joseph Gentle의 최신 글입니다. 먼저 읽고 보시면 좋습니다.
- 제가 틀렸었어요. CRDT가 미래입니다. https://news.hada.io/topic?id=2962
Xi Editor의 개발자인 Raph Levien 글도 참고할만 합니다.
https://github.com/xi-editor/xi-editor/…