HTML이든 뭐든 원본문서에서 일단 임시 구조화된 문서로 파싱을 한것을 다시 설정에 따라 파싱을 하는 작업을 하고 있다.

인덱싱에서 0.01초의 퍼포먼스 저하도 용납이 안되니 여러가지를 고민하지 않을 수가 없다.
일단 그 임시구조문서 파싱을 하는것인데, 파싱시 정규식을 쓸까 말까 고민을 많이 했다.

이 정규식이라는 놈이 정규식을 어떻게 쓰느냐에 따라 엄청난 퍼포먼스 차이가 나는 놈인지라 쓸데 안쓸데를 가려서 써야 한다는걸 이 문서를 보고 알았다.
또한 일반 문자열 search에서 무식한 방법으로 써칭을 하는 것보다 차라리 정규식 search를 하는게 훨씬 빠르다는 것도 말이다. (정규식 내부적으로 BM방법같은 빠른 문자열 써치를 쓴다고 한다.)

그런데 정규식을 전에 Python에서는 아무 생각없이 썼던게 사실이다. 뭐 퍼포먼스에 구애를 받지 않는 것이였지만 말이다.
이번에 C로 색인기를 구현하면서 어떻게 하면 정확하고 빠르게 파싱을 할것이고 Error에 강한 모듈을 만들 수 있을까 고민을 좀 했다.

일단. 정규식을 사용하기로 했다. (모듈화 하기 편하고, 소스코드가 지저분해질 위험이 적다는 이유와 gcc컴파일러 설치시 기본으로 포함이 되어 있는 범용성도 있구.)

쓰기위한 나만의 규약은 이렇다.

1. 정규식을 유연하게 만들기 보다는 의미가 정확하게 하자. 이런거 쓰지말자! (ex “.*” 말구 “\w{3}”이런식의 정확한 표현 추천) <- 백트래킹을 최소화 하는 식을 쓰자구!

2. 정규식 컴파일된(?) 구조체를 매번 반복해서 만들지 말자! (실제로 반복해서 만들 경우와 하나 만들어 놓고 그걸 가져다 쓰는건 엄청난 퍼포먼스 차이가 있었다. 그래서 나중에 리펙토링 했지만…)

C로 정규식을 쓰다보니 Python보다 적용되는 정규식 문법이 적다는게 느껴졌다. 일단 정규식 시험은 Python 쉘에서 시험해 보는데 그곳에서 돌아가는 정규식이 C에서는 안돌아가는 경우가 있었다.

위와같은 실험을 1000개의 문서에서 해봤는데 대략 정규식 컴파일 매번하는 경우와 한번하고 계속 가져다 쓰는 경우와는 평균적으로 0.05초 정도의 차이가 났다. 0.01초가 아쉬운 인덱싱인 경우에 엄청난 속도차이로 벌어질 수 있는 부분이다.

이번주 내내 고민했던 사항은…

1. 소스파일 접근횟수 줄인다.
2. 문서파싱의 정확도와 속도에 대한 가치판단과 그에따른 모듈구현.

1번은 문서 Buffer를 구현해서 해결..
2번은 정규식 최적화로 해결되었나????
뭔가 좋은 방법이 있다면 또 시도해보자구!

다음주에는 이 문서구조체들의 무결성을 체크해서 최적 check in 하는건데…
또 이 방법론으로 고민을 많이 하겠군.

무식하지만 정확한 방법을 쓸 것인가?
어느정도 문서들중에서 오류가 날 가능성이 있는것들만 일단 체크할 것인가?

고민이다…

색인문서 파싱에서 정규식 사용할까? by from __future__ import dream is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.