목차

1. 서론
2. 본론
3. 그래서 어떻게 개선을 해야할까...

1. 서론

  • 이제 렌더러는 어느 정도 완성되었으나... 느리다
  • 터지지는 않지만... 느리다

2. 본론


사실 타임아웃이 존재하면 좀 느려도 알아서 작동 멈추니 상관이 없다. 그러나 현재 오픈나무 구조에서는 타임아웃이 없으며 도입하기도 까다롭다. 그 놈의 파이썬 GIL 문제 때문에(1)

일단 가장 간단한 해답은 인클루드 제한이랑 문서 길이 제한을 매우 보수적으로 테스트 결과 하에 잡는 거라고 생각하지만... 현 테스트 결과 20만만 되어도 세월아 네월아 걸린다는 비관적인 전망만 접수하였다. 눈물만 흐른다 진짜 Go언어로 렌더러 짜야하나

일단 그래서 좀 최적화가 필요하다는 결론을 얻었다. 사실 이게 그냥 문서 작성에서는 순차적으로 차츰차츰 늘어나니 어느 순간 이상함을 느끼겠지만 이게 일반적인 문서 작성이 아니라 반달인 경우에는 음... 아마 한마음위키:알파위키-더시드위키 동시다발적 서버 장애 사건/경과 꼴 나지 않을까 매우 우려스럽다

3. 그래서 어떻게 개선을 해야할까...

... 아직 생각 중이다. 막막하다
(1) 원래는 한 스레드에선 타이머 작동 시키고 한 스레드에서는 함수 동작 시켜서 다른 스레드가 반대 스레드를 메모리 상에서 슉슈슉 죽어라 하면서 견제 해야 하는데 파이썬은 멀티스레드가 GIL 때매 못 쓰니 답이 없다 멀티프로세싱은 메모리 공유를 안하니 견제가 불가능하다 내가 모르는 걸지도 모르지만