jdom 성능

현재 원시 Java XML 처리 라이브러리 (Xerces)를 사용하고 있습니다. xml 노드에 임의 액세스해야하기 때문에 색소 파서를 사용할 수 없습니다. XML 파일을 파싱 할 때 CPU 사용량이 100 %가된다는 것을 알았습니다. 나는() processXMlfile에서 this-jdom 성능

while(hasFile){ 
processXMlfile(hasFile.next); 
}

처럼 처리하고 내가 구문 분석 및 처리 파일을 구축하고 작은 크기 (1-10킬로바이트)의 많은 수 있습니다.

JDOM 라이브러리로 이동하면 성능상의 이점이 있습니까?

출처

2012-04-12 user837208

당신이 VTD-XML 봤어 할 가능성이 두 배 이상 .... 처리량을 찾을 것인가? 중대성 XML 처리를 위해 그것은 아무도 차선책이 아닙니다 ... 기존의 java xml 처리 프레임 워크에 대한 포괄적 인 연구를 수행 한 최근의 연구 보고서를 읽으십시오 http://sdiwc.us/digitlib/journal_paper.php?paper=00000582.pdf –

병목 현상은 XML 파싱 일 가능성이 높으며 JDOM은 커버 아래에 동일한 XML 파서를 사용하기 때문에 아무런 차이가 없습니다.

많은 작은 파일을 구문 분석 할 때 중요한 요소는 파서 초기화 비용을 피하는 것입니다. 모든 파일에 대해 동일한 XML 구문 분석기 인스턴스를 다시 사용하십시오.

출처

2012-04-12 08:39:23

감사합니다 Michael . CPU 사용은 @ 100 %를 유지하지만 인스턴스를 다시 사용한 후에도 처리량이 크게 향상되었습니다 (약 40-50 개 파일에서 약 200 개 파일까지) – user837208

cpu 100 % 사용은 분명히 좋은 것입니다. –

나는 ... 때때로 시스템 관리자가 그것을 좋은 것으로 보지 않을 것입니다. 그들에게 붉은 깃발 상황 – user837208

JDOM 2.0.0은 많은 성능 문제를 해결합니다. 그 중 하나는 XML 파일의 '긴밀한 루프'처리와 직접 관련이 있습니다. 완전히 SAX 구문 분석의 설정을 제거합니다 JDOM 2.0.0에서 SAXEngine 개념을 사용하여

SAXBuilder saxbuilder = new SAXBuilder(); 
saxbuilder.setVariousConfigurations() 
SAXEngine saxengine = saxbuilder.buildEnine(); 

while(hasfile) { 
    processXML(saxengine, nextfile); 
}

: 당신은 뭔가를해야

http://hunterhacker.github.com/jdom/jdom2/apidocs/org/jdom2/input/sax/package-summary.html

은 보라 하부 구조. 이 설정 시간은 전반적인 프로 세싱의 큰 비중을 차지합니다.

여전히 100 % 실행 될 수 있지만, 유는

출처

2012-04-12 09:49:11 rolfl

답변

관련 문제