# 더 빠른 CRDT를 위해 최적화 하기

> Clean Markdown view of GeekNews topic #4744. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=4744](https://news.hada.io/topic?id=4744)
- GeekNews Markdown: [https://news.hada.io/topic/4744.md](https://news.hada.io/topic/4744.md)
- Type: news
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2021-08-02T10:31:01+09:00
- Updated: 2021-08-02T10:31:01+09:00
- Original source: [josephg.com](https://josephg.com/blog/crdts-go-brrr/)
- Points: 19
- Comments: 2

## Topic Body

- 기존 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를 기대 중

## Comments



### Comment 6122

- Author: xguru
- Created: 2021-08-02T10:32:01+09:00
- Points: 2

이 글은 아래 글의 저자인 구글 Wave 개발자 Joseph Gentle의 최신 글입니다. 먼저 읽고 보시면 좋습니다.

- 제가 틀렸었어요. CRDT가 미래입니다. https://news.hada.io/topic?id=2962

### Comment 6131

- Author: alstjr7375
- Created: 2021-08-02T17:32:23+09:00
- Points: 1
- Parent comment: 6122
- Depth: 1

Xi Editor의 개발자인 Raph Levien 글도 참고할만 합니다.

https://github.com/xi-editor/xi-editor/issues/1187#issuecomment-491473599