자바 스 크 립 트 수만 키워드 순간 일치 실현 코드

키워드 검색 을 언급 하면 먼저 연상 되 는 것 은 index Of,replace 와 같은 문자 함 수 를 사용 하 는 것 일 뿐 입 니 다.정규 표현 식 을 가장 많이 추가 하 는 것 일 뿐 입 니 다.실현 하기는 간단 하지만 그 뒤의 효율 문 제 는 자세히 고려 해 본 적 이 있 습 니까?예 를 들 어 포럼 의 키워드 필 터 는 일반적인 상황 에서 필터 해 야 할 키워드 의 수량 과 검 측 된 텍스트 의 길이 가 크 지 않 기 때문에 이 순간의 과정 은 주목 할 만 한 부분 이 많 지 않다.그러나 키워드 수가 손 에 꼽 히 지 않 고 수천 수만 에 달 하 며 검 사 를 기다 리 는 텍스트 도 장황 하 다 면 결 과 는 더 이상 낙관적 이지 않다.하나의 키워드 가 많 을 때마다 전체 텍스트 의 검색 을 한 번 더 늘 려 야 한 다 는 것 을 잘 알 고 있 습 니 다.최종 적 으로 걸 리 는 시간 은 받 아들 일 수 있 는 범 위 를 훨씬 초과 할 것 입 니 다.극단 적 인 키워드 검색 을 고려 한 이상,통상 적 으로 검색 을 옮 겨 다 니 는 것 은 분명히 통 하지 않 는 다.지금 은 자 바스 크 립 트 를 사용 하고 있 습 니 다.Hash 표를 사용 하지 않 으 면 이 언어 에 너무 떳떳 하지 못 합 니 다.표 특 천 만 의 지지 가 있 으 니 적은 공간 을 내 서 많은 시간 을 바 꿔 보 자.예 를 들 어 다음 과 같은 키워드 가 있 습 니 다.foo 1,foo 2,bar 1,bar 2.공간 으로 시간 을 바 꾸 려 면 검색 하기 전에 미리 처리 해 야 합 니 다.앞에서 JS 의 유연 하고 효율 적 인 시 계 를 언급 했 는데 나무의 구 조 를 사용 하 는 것 이 가장 유리 하 다 는 것 을 알 수 있다.모 르 더 라 도 괜 찮 습 니 다.최종 실현 구 조 는 다음 과 같은 코드 와 같 습 니 다.JSON 을 잘 아 는 것 도 친절 합 니 다.

var Root =
{
    f:
    {
        o:
        {
            o:
            {
: true,
: true
            }
        }
    },
    b:
    {
        a:
        {
             r:
            {
: true,
: true
            }
        }
    }
};
이 층 층 의 구 조 는 나무 와 같 습 니 다.모든 문 자 는 나무의 가지 이 고 마지막 문자 가 바로 나뭇잎 이 며 새로운 노드 가 없습니다.이 럴 때 는 글 의 모든 글 자 를 이 나 무 를 따라 내 려 가면 된다 는 것 을 알 아야 한다.나뭇잎 에 도달 할 수 있 는 것 은 현재 문자 가 키워드 의 하나 임 을 설명 합 니 다.중간 에 대응 하 는 가 지 를 찾 지 못 하면 당연히 키워드 가 아니다.예 를 들 어 foo 1 은 Root 구 조 를 따라 아래로 방문 한 다음 에 Root[f']['o']['o']['1']에 도착 하면 일치 하 는 것 을 완성 합 니 다.이후 foo 1 의 길 이 를 건 너 뛰 고 계속 뒤로 검색 합 니 다.따라서 전체 글 은 한 번 검색 하면 모든 키워드 의 위 치 를 찾 을 수 있다.JS 의 hash 표 성능 이 매우 높 기 때문에 이른바 나 뭇 가 지 를 찾 는 것 도 매우 빠르다.JS 의 유연성 때문에 이 효 과 를 실현 하 는 코드 역시 매우 짧다.사실 키워드 의 수량 은 검색 시간 과 그다지 상관 이 없다 는 것 을 알 수 있다.그것 은 나무의 너비 에 영향 을 주 었 을 뿐 글 의 길이 만 이 검색 시간 을 결정 하 는 것 이다.극한 테스트:키워드:성어 전집(19830 개)내용:주선 전집.txt(1659219 자)사용 시:935 ms(Chrome 26/i3-2312 의 CPU)160 만 자의 글,2 만 개의 키워드 와 일치 하 며 1 초도 안 됩 니 다.이 를 통 해 알 수 있 듯 이 자 바스 크 립 트 의 유연성 을 충분히 이용 하면 여전히 매우 큰 잠재력 을 발휘 할 수 있다.

좋은 웹페이지 즐겨찾기