새로운:개발 일지/비동기 처리의 허와 실

목차

1. 서론
2. 렌더링 속도 문제는 비동기 때문이 아님
3. 그러면 일반 페이지에서 느린 건? 이건 비동기로 안되나?
4. 결론

1. 서론 _{✎ ⊖}

항상 오픈나무의 최적화 이야기가 나오면 비동기 도입 이야기가 나오는데

실제로는 비동기 처리보단 다른 곳에 항상 중점을 두고 있는 이유를 나름 변명 아닌 변명으로 설명하려고 한다

렌더링이 오래 걸리는 것은 비동기 처리의 문제가 아니다

정규식의 비효율성, 백트래킹 남발 및 재귀적 처리의 문제이다

-> 비동기와 멀티스레드의 차이를 보여주는 사진 출처

비동기 처리에서는 결국 중간 대기시간이 있는 작업이 아닌한 동일 작업량에 대해서는 동일한 소요 시간을 가진다

또한 문자열 처리는 비동기 처리를 한다고 해도

문자열 처리는 더 낮은 수준의

코루틴으로 나눌 수 없기 때문에 비동기 처리의 이점이 없다⁽¹⁾

결국 현재 렌더러의 구조적인 문제로써 AST 같은 구조로 렌더러를 바꿔야 모든 문제가 해결된다.

아니 그럼 그걸 알고 있는데 왜 안 고침?

~~그걸 할만한 시간이 없어서 미루고 미루다가...~~

이번에 새로 작정할 렌더러부터는 제대로 파서 구조로 짜려고 노력은... 해야겠다

일반적으로 SQLite는 단일 스레드로 동작한다 이 말은 즉슨

동기

비동기

결국 순서에만 차이가 있을 뿐이고 최종 결과물을 보여주는 시간에는 차이가 거의 없다

그리고 추가로 동기 상태여도 스레드는 사용하므로 파이썬 스레드를 고려했을 때

-> 파이썬에서 스레드를 쓰면 GIL로 인해서 각 스레드마다 돌아가면서 작동한다 출처

한마디로 IO 작업 등이 있지 않는 한 비동기 상태와 체감 성능 차이는 거의 없다⁽²⁾

오픈나무에 필요한 건 비동기가 아니라

제대로된 병렬 처리 지원⁽³⁾과 새로운 효율적인 구조를 가진 렌더러이다.

그리고 추진하고 있다.

(1) 비동기 처리는 IO처리나 통신 대기 같은 곳에서 유리하고 이런 일반적인 용도에선 별 차이 없다

(2) 물론 비동기가 좀 더 경량이긴 하겠지만

(3) 이게 Golang으로 이전을 추진하고 있는 이유이기도 하고