<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />JMPers 님, 안녕하세요. 당신과 JSL 성능 개선 이야기를 공유하겠습니다. WORDS를 사용하여 매우 긴 문자열 (> 200,000 자)을 파싱하는 경우 도움이됩니다.
JSL에서 성능 문제가 발생했습니다. 정말 긴 문자열에 대해 WORDS 기능의 성능을 저하시키기 위해 추적했습니다. WORDS 함수는 공백이나 제공된 구분 기호를 사용하여 문자열을 목록으로 구문 분석합니다. 일반적으로이 함수는 매우 빠르지 만 길이가 약 200,000자인 문자열의 경우 속도가 느려집니다. 네, 그 문자열은 길고 길어요. 다음은 실적 그래프입니다.
그래서 나는 더 나은 쥐덫을 썼다. 사실 그래프에서 볼 수 있듯이 두 개의 쥐덫을 썼습니다. 첫 번째 (MYWORDS1)는 OPEN을 사용하여 텍스트 문자열을 데이터 세트로 엽니 다. 두 번째 (MYWORDS2)는 대략 100,000 바이트 덩어리로 데이터를 자르고 청크에서 단어를 실행합니다. 둘 모두 문자 수가 많을 때 WORDS에 비해 우수한 성능을 보입니다.
MYWORDS1 함수가 약간 더 좋긴하지만, 텍스트에 캐리지 리턴과 줄 바꿈이 있으면 문제가 있습니다. 따라서 MYWORDS2를 프로덕션 용도로 사용하려고합니다.
MYWORDS1에서 사용 된 기술에는 많은 가능성이 있습니다! Peter Wiebe에게 OPEN을 사용하고 코드를 검토하고 개선하는 데 대한 최초의 아이디어에 감사드립니다. 다음은 데이터 문자열에 텍스트 문자열을 열고 구분 된 각 문자열을 개별 행으로 구문 분석하는 방법을 보여주는 간단한 예입니다.
big_string = "이것은 공백으로 구분 된 샘플 문자열입니다" ;
tmpdt = 열다 ( Blob에 대한 char ( "WordColumn" || "" || big_string ) , 본문 ,
endofline ( 다른 ) , 외로운 ( "" ) , 엔도 필드 ( 탭 ) , 보이지 않는 ) ;
BTW의 결과는 3GB RAM과 i5-2520M CPU 2.50GHz 프로세서가있는 32 비트 XP 시스템에서 JMP 9.0.2를 사용했을 때의 결과입니다. 필자는 Windows 7에서 JMP 9 및 JMP 10 베타를 사용하여 함수를 테스트했으며 그 결과는 비슷했습니다.
함수 및 일부 테스트 코드에 대한 코드를 첨부했습니다.
즐겨!
베드로
