2008-08-28 11 views
14

मुझे यह जानने की ज़रूरत है कि विभिन्न XML टूल (पार्सर्स, वैधकर्ता, XPath अभिव्यक्ति मूल्यांकनकर्ता, आदि) का प्रदर्शन इनपुट दस्तावेज़ के आकार और जटिलता से कैसे प्रभावित होता है। क्या वहां संसाधन हैं जो दस्तावेज करते हैं कि कैसे सीपीयू समय और स्मृति उपयोग प्रभावित होते हैं ... अच्छा, क्या? बाइट्स में दस्तावेज़ का आकार? नोड्स की संख्या? और रिश्ते रैखिक, बहुपद, या बदतर है?एक्सएमएल पार्सर्स/वैधकर्ताओं की एल्गोरिदमिक जटिलता

अद्यतन

IEEE कम्प्यूटर पत्रिका में एक लेख में, खंड 41 एन.आर. 9, सितम्बर 2008, लेखकों चार लोकप्रिय XML पार्सिंग मॉडल (डोम, SAX, StAX और VTD) सर्वेक्षण। वे कुछ बहुत ही बुनियादी प्रदर्शन परीक्षण चलाते हैं जो दिखाते हैं कि इनपुट फ़ाइल का आकार 1-15 केबी से 1-15 एमबी तक या लगभग 1000x बड़ा होने पर डीओएम-पार्सर का थ्रूपुट कम हो जाएगा। अन्य मॉडलों का थ्रूपुट महत्वपूर्ण रूप से प्रभावित नहीं होता है।

दुर्भाग्य से उन्होंने नोड्स/आकार की संख्या के फ़ंक्शन के रूप में थ्रूपुट/मेमोरी उपयोग जैसे अधिक विस्तृत अध्ययन नहीं किए।

लेख here.

है अद्यतन

मैं इस समस्या का कोई औपचारिक उपचार खोजने में असमर्थ था। इसके लायक होने के लिए, मैंने कुछ प्रयोग किए हैं जो XML दस्तावेज़ में नोड्स की संख्या को बाइट्स में दस्तावेज़ के आकार के फ़ंक्शन के रूप में मापते हैं। मैं गोदाम प्रबंधन प्रणाली पर काम कर रहा हूं और एक्सएमएल दस्तावेज ठेठ गोदाम दस्तावेज हैं, उदाहरण के लिए उन्नत शिपिंग नोटिस इत्यादि

नीचे दिया गया ग्राफ बाइट्स में आकार और नोड्स की संख्या के बीच संबंध दिखाता है (जो दस्तावेज़ के मेमोरी पदचिह्न के लिए डीओएम मॉडल के अनुपात में होना चाहिए)। विभिन्न रंग विभिन्न प्रकार के दस्तावेज़ों से मेल खाते हैं। पैमाने लॉग/लॉग है। ब्लैक प्वाइंट ब्लू पॉइंट्स के लिए सबसे अच्छा फिट है। यह ध्यान रखना दिलचस्प है कि सभी प्रकार के दस्तावेजों के लिए, बाइट आकार और नोड आकार के बीच संबंध रैखिक है, लेकिन आनुपातिकता का गुणांक बहुत अलग हो सकता है।

benchmarks-bytes_vs_nodes

+0

यूएचएच ग्राफ! हमेशा अच्छा। अच्छे अपडेट! – svrist

उत्तर

3

तो मुझे लगता है कि समस्या का सामना करना पड़ रहा था और कुछ भी गूगल पर मैं शायद यह मेरे स्वयं करने की कोशिश करेंगे नहीं पा सके।

कुछ "बैक-ऑफ-ए-लिफाफा" सामान यह महसूस करने के लिए कि यह कहां जा रहा है। लेकिन मुझे थोड़े से एक एक्सएमएल पार्सर कैसे करना है इसका विचार करने की आवश्यकता होगी। गैर algorithmical मानक के लिए यहां एक बार देख ले:

1

मुझे लगता है कि बहुत सारे चर एक सरल मीट्रिक जब तक आप बनाने जटिलता साथ आने के लिए शामिल नहीं है बहुत सारी धारणाएं

एक सरल SAX शैली पार्सर दस्तावेज़ आकार और स्मृति के लिए फ्लैट के संदर्भ में रैखिक होना चाहिए।

XPath अभिव्यक्ति की जटिलता एक बड़ी भूमिका निभाता है क्योंकि केवल XP दस्तावेज़ की तरह कुछ वर्णन करना असंभव होगा।

इसी प्रकार स्कीमा सत्यापन के लिए, एक बड़ी लेकिन सरल स्कीमा अच्छी तरह से रैखिक हो सकती है, जबकि एक छोटी स्कीमा जिसमें अधिक जटिल संरचना होती है, वह खराब रनटाइम प्रदर्शन दिखाती है।

अधिकांश प्रदर्शन प्रश्नों के साथ सटीक उत्तरों प्राप्त करने का एकमात्र तरीका यह मापना है और देखें कि क्या होता है!

1

रोब वॉकर सही है: समस्या पर्याप्त विस्तार से निर्दिष्ट नहीं है। केवल पार्सर्स (और इस बात को अनदेखा करते हुए कि वे सत्यापन करते हैं या नहीं), दो मुख्य स्वाद हैं: पेड़-आधारित-सोच डीओएम-और स्ट्रीमिंग/घटना-आधारित-सोच SAX (पुश) और StAX (खींचें)। विशाल सामान्यताओं में बोलते हुए, पेड़-आधारित दृष्टिकोण अधिक स्मृति का उपभोग करते हैं और धीमे होते हैं (क्योंकि आपको पूरे दस्तावेज़ को पार्स करना समाप्त करना होगा), जबकि स्ट्रीमिंग/घटना-आधारित दृष्टिकोण कम स्मृति का उपभोग करते हैं और तेज़ी से होते हैं। पेड़-आधारित पार्सर्स को आम तौर पर उपयोग करने में आसान माना जाता है, हालांकि एसएक्स पर स्टैक्स को भारी सुधार (आसानी से उपयोग में) के रूप में घोषित किया गया है।

0

मैं अपने आवेदन में बहुत बड़ी एक्सएमएल फाइलों को लोड करने की योजना बना रहा था। मैंने यहां स्टैक ओवरफ़्लो पर प्रश्न पूछा: Fastest Possible XML handling for very large documents

और हाँ, यह पार्सिंग हिस्सा था, जो बाधा थी।

मैं एक्सएमएल पार्सर्स का उपयोग नहीं कर रहा था। इसके बजाए, मैंने गति के लिए अनुकूलन के रूप में कुशलतापूर्वक एक वर्ण को वर्णित किया। इसके परिणामस्वरूप आंतरिक डेटा संरचना के पढ़ने, विश्लेषण और लोडिंग के लिए 3 गीगाहर्ट्ज़ विंडोज पीसी पर प्रति सेकंड 40 एमबी की गति हुई।

मुझे यह सुनने में बहुत दिलचस्पी होगी कि विभिन्न एक्सएमएल पार्सिंग मोड इसकी तुलना कैसे करते हैं।