🤜🏻 ⛩️ 🏧 बेंचमार्क HTML पार्सर 🧘🏼 👇🏼 🛃

मैंने एक द्वीप में पायथन से एरलांग तक एक सेवा का एक टुकड़ा कॉपी किया । सेवा स्वयं HTTP पर एक ही प्रकार के HTML पृष्ठों की एक महत्वपूर्ण राशि डाउनलोड करने और उनसे कुछ जानकारी निकालने के लिए प्रतिबद्ध है। सेवा का मुख्य CPU लोड DOM ट्री में HTML को पार्स कर रहा है।

सबसे पहले, मैं पायथन से इस्तेमाल किए गए lxml.etree.HTML () के साथ एरलंग मोचीवेब_एचटीएमएल पार्सर के प्रदर्शन की तुलना करना चाहता था। उन्होंने सबसे सरल बेंचमार्क खर्च किया, आवश्यक निष्कर्ष बनाया, और फिर सोचा कि बेंचमार्क में एक जोड़े को अधिक पार्सर्स और प्लेटफार्मों को जोड़ना अच्छा होगा, इसे और अधिक सुंदर बनाएं, कोड प्रकाशित करें और एक लेख लिखें।
फिलहाल, मैं निम्नलिखित संयोजनों में एरलांग , पायथन , PyPy , NodeJS और C में बेंचमार्क लिखने में कामयाब रहा:

एर्लांग - mochiweb_html
CPython - lxml.etree.HTML
सीपीथॉन - सुंदरसुपर 3
सीपीथॉन - ब्यूटीफुल 4
CPython - html5lib
PyPy - ब्यूटिफुलसुप ३
PyPy - सुंदरसुपर 4
PyPy - html5lib
नोड.जेएस - चीयरियो
नोड.जेएस - htmlparser
नोड.जेएस - jsdom
सी - libxml2 (संदर्भ के लिए)

परीक्षण पार्सर के एन पुनरावृत्तियों की प्रसंस्करण गति और चरम मेमोरी खपत की तुलना करता है।

साज़िश: कौन तेज़ है - अजगर या PyPy? Erlang इम्युनिटी पार्सिंग गति और स्मृति खपत को कैसे प्रभावित करती है? V8 NodeJS कितनी तेजी से है? और शुद्ध C में कोड यह सब कैसे दिखता है?

मामले

सबसे अधिक संभावना है कि आप उनसे परिचित हैं, लेकिन इसे क्यों नहीं दोहराएं?

गैर-सख्त HTML पार्सर एक HTML पार्सर है जो अमान्य HTML कोड (असूचीबद्ध टैग, संकेत > < अंदर <script> टैग, अनस्पैप्ड एम्परसेंड & वर्ण, बिना उद्धरण चिह्न आदि के विशेषता मान) को संसाधित कर सकता है। यह स्पष्ट है कि प्रत्येक टूटे हुए HTML को पुनर्स्थापित नहीं किया जा सकता है, लेकिन आप इसे उस रूप में ला सकते हैं जिसमें यह ब्राउज़र को ले जाता है। यह उल्लेखनीय है कि इंटरनेट पर पाए जाने वाले अधिकांश HTML एक डिग्री या किसी अन्य, अमान्य हैं!
DOM ट्री - डॉक्यूमेंट ऑब्जेक्ट मॉडल, सख्ती से बोलना, DOM वह API है जो HTML डॉक्यूमेंट्स में हेरफेर करने के लिए ब्राउज़र में जावास्क्रिप्ट प्रदान किया जाता है। हम कार्य को थोड़ा सरल करेंगे और हम मान लेंगे कि यह एक डेटा संरचना है, जो एचटीएमएल दस्तावेज़ की संरचना का एक पेड़ जैसा प्रतिनिधित्व है। पेड़ की जड़ में <html> तत्व है, इसके बच्चे <head> और <body> और इसी तरह। उदाहरण के लिए, पायथन में, एक दस्तावेज़

 <html lang="ru-RU"> <head></head> <body>Hello, World!</body> </html>

आप सबसे सरल रूप में कल्पना कर सकते हैं कि कैसे

 ("html", {"lang": "ru-RU"}, [ ("head", {}, []), ("body", {}, ["Hello, World!"]) ])

आमतौर पर, HTML रूपांतरण या डेटा निष्कर्षण के लिए DOM ट्री में परिवर्तित किया जाता है। एक पेड़ से डेटा निकालने के लिए XPath या CSS चयनकर्ताओं का उपयोग करना बहुत सुविधाजनक है।

प्रतियोगियों

Erlang
- Mochiweb html parser । Erlang के लिए केवल गैर-सख्त HTML पार्सर। एरलांग में लिखा है।
CPython
- lxml.etree.HTML बाइंडिंग libxml2। Cython
- सुंदरसुपर 3 पायथन एचटीएमएल डोम पार्सर (तीसरा संस्करण)।
- BeautifulSoup 4 HTML DOM पार्सर प्लग-इन बैकएंड के साथ।
- HTML5lib HTML5-उन्मुख पार्सर डोम डोम में लिखा गया है।
PyPy (CPython के समान पार्सर्स, lxml को छोड़कर)
- सुंदरसुपर ३
- सुंदरसुपर ४
- html5lib
Node.js
- jQuery एपीआई समर्थन के साथ जयकार जेएस HTML डोम पार्सर
- शुद्ध जेएस में HTMLparser HTML DOM पार्सर
- jsdom को JS HTML DOM पार्सर में लिखा है जो ब्राउज़र API के समान परिष्कृत API के साथ है
सी
- libxml2 C गैर-सख्त HTML SAX / DOM पार्सर में लिखा गया है।

लक्ष्यों

सामान्य तौर पर, HTML पार्सिंग (साथ ही JSON) दिलचस्प है क्योंकि एक दस्तावेज़ को चरित्र द्वारा चरित्र को देखने की आवश्यकता होती है। इसमें कोई निर्देश नहीं हैं जैसे "अगले 10Kb एक ठोस पाठ है, इसे इस रूप में कॉपी करें।" यदि हम पाठ में <p> टैग से मिलते हैं, तो हमें क्रमिक रूप से </ निर्माण की उपस्थिति के लिए सभी बाद के पात्रों के माध्यम से देखना होगा। तथ्य यह है कि HTML मान्य नहीं हो सकता है हमें "2 बार सब कुछ जांचने" के लिए मजबूर करता है। क्योंकि, उदाहरण के लिए, यदि हम <option> से मिले हैं, तो यह इस तथ्य से बहुत दूर है कि हम समापन </option> से मिलेंगे। दूसरी समस्या जो आमतौर पर ऐसे प्रारूपों के साथ होती है, वह है विशेष पात्रों का बचना। उदाहरण के लिए, यदि पूरा दस्तावेज <html>...100 ... & ... 100 ...</html> <html>...100 ... & ... 100 ...</html> , तो पार्सर को केवल परिवर्तन के साथ टैग की सामग्री की पूरी प्रतिलिपि को स्मृति में बनाने के लिए मजबूर किया जाएगा - "& amp;", "&" में परिवर्तित हो गया (हालांकि कुछ पार्सर ऐसे पाठ को 3 में तोड़ देते हैं; व्यक्तिगत टुकड़े)।

स्मृति में एक बड़ी संरचना बनाने की आवश्यकता - छोटी वस्तुओं का एक पेड़, कई छोटी वस्तुओं को बनाने के लिए स्मृति प्रबंधन, कचरा कलेक्टर, ओवरहेड पर सख्त आवश्यकताओं को लागू करता है।

हमारा बेंचमार्क हम चाहते हैं:

विभिन्न गैर-सख्त HTML DOM पार्सर के प्रदर्शन और मेमोरी उपयोग की तुलना करें।
पार्सर की स्थिरता का अध्ययन करने के लिए। क्या एक पृष्ठ का प्रसंस्करण समय और मेमोरी की मात्रा में पुनरावृत्तियों की संख्या में वृद्धि होगी?
पार्सिंग गति और मेमोरी की खपत HTML दस्तावेज़ के आकार पर निर्भर करती है।
ठीक है, मंच की प्रभावशीलता का मूल्यांकन करने के लिए: लाइन गति, स्मृति प्रबंधन दक्षता

हम टूटे दस्तावेजों की वसूली की पूर्णता के मामले में पार्सर की गुणवत्ता की जांच नहीं करेंगे। एपीआई की सुविधा और पेड़ के साथ काम करने के लिए उपकरणों की उपलब्धता की तुलना भी पर्दे के पीछे छोड़ दी जाती है।

परीक्षण की स्थिति और कार्यप्रणाली

कार्यक्रम मेमोरी में डिस्क से एक बार एक दस्तावेज पढ़ता है और फिर इसे एन बार अनुक्रमिक रूप से लूप में रखता है।
प्रत्येक पुनरावृत्ति पर पार्सर को एक संपूर्ण डोम ट्री की स्मृति में बनाना चाहिए।
एन पुनरावृत्तियों के बाद, प्रोग्राम लूप के रन टाइम को प्रिंट करता है और बाहर निकलता है।

प्रत्येक पार्सर को N = 10, 50, 100, 400, 600 और 1000 पुनरावृत्तियों पर कई HTML दस्तावेजों के एक सेट पर लॉन्च किया गया है।
हम यूजर सीपीयू, सिस्टम सीपीयू, रियल रनटाइम और (लगभग?) पीक मेमोरी खपत को /usr/bin/time मापते हैं।
HTML दस्तावेज़:

page_google.html (116Kb) - Google परिणाम, प्रति पृष्ठ 50 परिणाम। पेज में बहुत सारे HTML और JS एम्बेडेड हैं, एक छोटा सा टेक्स्ट, एक लाइन में सभी HTML।
page_habrahabr-70330.html (1,6Mb) - 900 टिप्पणियों के साथ हब पर एक लेख। एक बहुत बड़ा पृष्ठ, कई टैग, स्थान और टैब।
page_habrahabr-index.html (95Kb) - habrahabr मुख्य पृष्ठ। विशिष्ट ब्लॉग पेज।
page_wikipedia.html (99Kb) - विकिपीडिया लेख। मुझे एक ऐसा पृष्ठ चाहिए था जिस पर बहुत सारे पाठ और कुछ टैग होंगे, लेकिन मैंने सबसे सफल नहीं चुना। परिणाम बहुत सारे टैग और इनलाइन सीएसएस है।

वास्तव में, मुझे एहसास हुआ कि अधिकांश आकार के दस्तावेज़ केवल अंत में ही हैं, लेकिन फिर से तैयार नहीं किया, क्योंकि माप की प्रक्रिया में ही बहुत समय लग जाता है। और इसलिए पेज के आकार पर भी निर्भरता को ट्रैक करना दिलचस्प होगा। UPD: लेख का दूसरा भाग तैयार किया जा रहा है, इसमें हम TOP1000 एलेक्सा से साइटों को पार्स करेंगे।

मैंने Ubuntu 3.5.0-19-जेनेरिक x86_64 पर क्रमिक रूप से परीक्षण चलाए, प्रोसेसर इंटेल कोर i7-3930K CPU @ 3.20GHz × 12. (यदि 12 कोर के लिए, तो क्या परीक्षण क्रमिक रूप से चलते हैं? एह ...)

कोड

सभी कोड github पर उपलब्ध है । आप इसे स्वयं चलाने का प्रयास कर सकते हैं, विस्तृत निर्देश README फाइल में हैं। नहीं भी - मैं दृढ़ता से मुझे विश्वास नहीं करने की सलाह देता हूं, लेकिन यह जांचने के लिए कि आपके वातावरण में परीक्षण कैसे व्यवहार करते हैं!
युक्ति: यदि आप प्लेटफ़ॉर्म के केवल भाग का परीक्षण करना चाहते हैं (उदाहरण के लिए, आप अपने लिए Erlang या PyPy स्थापित नहीं करना चाहते हैं), तो यह आसानी से PLATFORMS पर्यावरण चर द्वारा निर्धारित किया जाता है।
मुझे अन्य भाषाओं में पार्सर्स के कार्यान्वयन के साथ-अनुरोधों को खींचने में खुशी होगी (PHP? जावा? ~~.NET?~~ रूबी?), मैं परिणामों में जोड़ने की कोशिश करूंगा (मूल कार्यान्वयन मुख्य रूप से दिलचस्प हैं - लिबक्सएमएल के लिए बाइंडर्स आमतौर पर गति में भिन्न नहीं होते हैं)। कुछ अन्य दिलचस्प HTML फ़ाइलों (टैग्स के बड़े नेस्टिंग, विभिन्न फ़ाइल आकार) पर परीक्षण चलाने का प्रयास करना दिलचस्प होगा।

परिणाम

यहाँ CSV फ़ाइलों के परिणाम के रूप में कच्चे माप परिणाम हैं -1000 . csv परिणाम -600.csv परिणाम -400.csv परिणाम -100.csv परिणाम -50.csv परिणाम-10 . csv । आइए उनका विश्लेषण करने की कोशिश करें, इसके लिए हम आर भाषा (स्क्रिप्ट या फ़ोल्डर में एक बेंचमार्क के साथ रिपॉजिटरी में स्थित) में एक स्क्रिप्ट का उपयोग करते हैं।

गति

पुनरावृत्तियों की संख्या पर पार्सर की गति की निर्भरता का अध्ययन करने के लिए, हम [पुनरावृत्तियों की संख्या पर एक पृष्ठ] की प्रक्रिया की निर्भरता के हिस्टोग्राम का निर्माण करते हैं। हम एक पृष्ठ को पार्सर के समय के रूप में मानते हैं, पुनरावृत्तियों की संख्या से विभाजित। आदर्श रूप से, पार्सर की गति पुनरावृत्तियों की संख्या पर निर्भर नहीं होनी चाहिए, बल्कि यह ( जेआईटी के कारण , उदाहरण के लिए) बढ़नी चाहिए।
सभी रेखांकन क्लिक करने योग्य हैं! आँखें मत तोड़ना!

पार्सर के पुनरावृत्तियों की संख्या पर एक दस्तावेज़ को संसाधित करने के लिए समय की निर्भरता (इसके बाद, प्रत्येक HTML पृष्ठ के लिए, एक अलग अनुसूची)।

एक ही ऊंचाई के कॉलम - अच्छा, अलग - बुरा। यह देखा जा सकता है कि अधिकांश पार्सरों के लिए कोई निर्भरता नहीं है (सभी कॉलम समान ऊंचाई हैं)। PyPy के तहत एकमात्र अपवाद BeautifulSoup 4 और html5lib हैं; किसी कारण से, उनका प्रदर्शन पुनरावृत्तियों की संख्या में वृद्धि के साथ घट जाता है। यही है, अगर PyPy पर आपका पार्सर लंबे समय तक काम करना चाहिए, तो प्रदर्शन धीरे-धीरे कम हो जाएगा। अचानक ...

अब सबसे दिलचस्प चार्ट प्रत्येक पार्सर द्वारा एक पृष्ठ की औसत प्रसंस्करण गति है। एक बॉक्स-प्लॉट आरेख बनाएँ।
किसी दस्तावेज़ को संसाधित करने के लिए औसत समय।

बॉक्स जितना ऊँचा होता है, उतना ही धीमा काम करता है। क्षेत्र में बड़ा बॉक्स, मूल्यों का प्रसार (यानी, पुनरावृत्तियों की संख्या पर प्रदर्शन की निर्भरता अधिक)। आप देख सकते हैं कि C में पार्सर लीड में है, इसके बाद lxml.etree , लगभग NodeJS और Erlang के लिए पार्सर तक सही है, फिर PyPy के लिए bsoup3 parser, CPython के लिए persers और फिर, एक बड़े अंतर से, PyPy पर चलने वाले समान पार्सर। क्या आश्चर्य है! PyPy सभी को मिला देता है।
एक और विचित्रता यह है कि पायथन में 3 पार्सर किसी कारण से विकिपीडिया पृष्ठ की तरह नहीं है :-)।

उदाहरण सारणीबद्ध डेटा:

  > सबसेट (रेस, (फ़ाइल == "पेज_ओएनएचओकेजी") & (लूप्स == १०००)) [सी ("प्लेटफ़ॉर्म", "पार्सर", "पार्सर.स", "रियल.स", "user.s ")]
     मंच पार्सर parser.s real.s user.s
 6 c-libxml2 libxml2_html_parser.c 2.934295 2.93 2.92
 30 एरलांग मोचीवेब_एचटीएमएल। 13.346997 13.51 13.34
 14 नोडज्स चीयरियो_परसर 5.जेड। 5.303000 5.37 5.36
 38 नोडज htmlparser_parser.js 6.686000 6.72 6.71
 22 नोडज jsdom_parser.js 98.288000 98.42 98.31
 33 pypy bsoup3_parser.py 40.779929 40.81 40.62
 57 pypy bsoup4_parser.py 434.215878 434.39 433.91
 41 pypy html5lib_parser.py 361.008080 361.25 360.46
 65 अजगर bsoup3_parser.py 78.566026 78.61 78.58
 49 अजगर bsoup4_parser.py 33.364880 33.45 33.43
 60 python html5lib_parser.py 200.672682 200.71 200.70
 67 अजगर lxml_parser.py 3.060202 3.08 3.08

स्मृति

अब स्मृति उपयोग पर नजर डालते हैं। सबसे पहले, आइए देखें कि मेमोरी की खपत पुनरावृत्तियों की संख्या पर निर्भर करती है। फिर से हिस्टोग्राम बनाएं। आदर्श रूप से, एक पार्सर के सभी कॉलम समान ऊंचाई के होने चाहिए। यदि खपत पुनरावृत्तियों की संख्या के साथ बढ़ती है, तो यह एक स्मृति रिसाव या कचरा कलेक्टर के साथ समस्याओं का संकेत देता है।
पार्सर के पुनरावृत्तियों की संख्या के आधार पर मेमोरी की खपत।

दिलचस्प। PyPy के तहत Bsoup4 और html5lib ने 1MB फ़ाइल पर 1000 पुनरावृत्तियों के बाद 5GB मेमोरी ली। (मैं यहां केवल 2 ग्राफिक्स लाया, क्योंकि बाकी में एक ही तस्वीर है)। यह देखा जा सकता है कि पुनरावृत्तियों की संख्या में वृद्धि के साथ, भस्म स्मृति भी लगभग रैखिक रूप से बढ़ती है। यह पता चला है कि PyPy बस Bsoup4 और html5lib पार्सर्स के साथ संगत नहीं है। मुझे नहीं पता कि यह किसके साथ जुड़ा हुआ है और किसे दोष देना है, लेकिन यह स्पष्ट है कि उपयोग किए गए सभी पुस्तकालयों के साथ संगतता की जांच किए बिना PyPy का उपयोग करना एक बहुत ही जोखिम भरा कार्य है।
यह पता चला है कि इन पार्सर के साथ PyPy का संयोजन समाप्त हो गया है। आइए उन्हें ग्राफ़ से निकालने की कोशिश करें:
पार्सर के पुनरावृत्तियों (Bsoup4 और PyPy पर html5lib के बिना) के आधार पर मेमोरी की खपत।

हम देखते हैं कि सी में पार्सर के लिए सभी कॉलम लगभग ऊंचाई में समान हैं। वही lxml.etree के लिए जाता है। अधिकांश पार्सर्स के लिए, 10 पुनरावृत्तियों में मेमोरी की खपत थोड़ी कम है। हो सकता है कि सिर्फ time पास इसे मापने का समय न हो। NodeJS jsdom parser अजीब तरह से व्यवहार करता है - यह कुछ पन्नों के बजाय एक यादृच्छिक तरीके से स्मृति में कूदता है, लेकिन सामान्य तौर पर, समय के साथ स्मृति की खपत में वृद्धि दिखाई देती है। शायद कचरा संग्रह के साथ कुछ समस्याएं।

शेष पार्सर के लिए औसत मेमोरी खपत की तुलना करें। बॉक्स-प्लॉट बनाएँ।
औसत मेमोरी खपत।

हम देखते हैं कि यह व्यवस्था गति की तुलना में लगभग समान है, लेकिन एरलांग की मेमोरी खपत नोड्स की तुलना में कम है। lxml.etree को C libxml2 की तुलना में लगभग 2 गुना अधिक मेमोरी की आवश्यकता होती है, लेकिन किसी भी अन्य पार्सर की तुलना में कम। NodeJS पार्सर jsdom कुछ हद तक तस्वीर से बाहर हो जाता है, अन्य NodeJS पार्सर्स की तुलना में ~ 2 गुना अधिक मेमोरी का उपभोग करता है - जाहिर है यह DOM ट्री तत्वों के लिए अतिरिक्त विशेषताओं के निर्माण से जुड़ा एक महत्वपूर्ण ओवरहेड है।
उदाहरण सारणीबद्ध डेटा:

 > सबसेट (रेस, (फ़ाइल == "पेज_ओएनओएस") & (लूप्स == १०००)) [सी ("प्लेटफ़ॉर्म", "पार्सर", "मैक्स आरएसएस")]
     मंच पार्सर अधिकतम
 6 c-libxml2 libxml2_html_parser.c 2240
 30 एरलांग मोचीवेब_एचटीएमएल। 21832
 14 नोडज्स चीयरियो_परसर .जेएस 49972
 38 नोडज htmlparser_parser.js 48740
 22 नोडज jsdom_parser.js 119256
 33 pypy bsoup3_parser.py 61756
 57 pypy bsoup4_parser.py 1701676
 41 pypy html5lib_parser.py 1741944
 65 अजगर bsoup3_parser.py 42192
 49 अजगर bsoup4_parser.py 54116
 60 अजगर html5lib_parser.py 45496
 67 अजगर lxml_parser.py 9364

कार्यक्रम का शुभारंभ करने के लिए उपरि

यह HTML पार्सर का इतना परीक्षण नहीं है क्योंकि यह पता लगाने की कोशिश है कि कंसोल उपयोगिताओं को लिखने के लिए किस प्लेटफॉर्म का उपयोग किया जाना चाहिए। बस एक छोटा सा जोड़ (क्योंकि हमारे पास पहले से ही डेटा है)। प्लेटफ़ॉर्म ओवरहेड वह समय है जो प्रोग्राम सीधे काम पर नहीं खर्च करता है, बल्कि इसकी तैयारी पर है (पुस्तकालयों को आरम्भ करना, HTML फ़ाइल पढ़ना, आदि)। इसकी गणना करने के लिए, हम उस समय से घटाते हैं जब time उपयोगिता घट गई - "time.s", वह समय जो पार्सर चक्र के आसपास मापा गया था - "parser.s"।

यह देखा जा सकता है कि ओवरहेड ज्यादातर मामलों में नगण्य है। यह उल्लेखनीय है कि एर्लैंग पायथन से तुलनीय है। हम मान सकते हैं कि यह बड़े पैमाने पर पुस्तकालयों पर निर्भर करता है कि कार्यक्रम आयात करता है।

निष्कर्ष

जैसा कि आप देख सकते हैं, सी कार्यान्वयन बाकी से आगे है (लेकिन इसमें कोड अधिक निकला)।

अजगर (lxml.etree.HTML) को libxml2 बांधना लगभग एक ही गति से काम करता है, लेकिन 2 गुना अधिक मेमोरी (सबसे अधिक संभावना है कि इंटरप्रेटर ओवरहेड) का उपभोग करता है। यह पता चला है कि पायथन में पसंदीदा पार्सर एलएक्सएमएल है।

नग्न Erlang पर पार्सर आश्चर्यजनक रूप से उच्च परिणाम दिखाता है, "हर छींक के लिए डेटा की प्रतिलिपि बनाने" के Erlang के कारण। गति NodeJS पर सरल पार्सर और पायथन पार्सर की तुलना में अधिक है। मेमोरी की खपत केवल C और lxml के लिए कम है। स्थिरता उत्कृष्ट है। इस तरह के पार्सर को उत्पादन में जारी किया जा सकता है (जो मैंने किया था)।

NodeJS पर सरल पार्सर बहुत तेजी से काम करते हैं - नियमित रूप से लिबक्सएमएल की तुलना में 2 गुना धीमा। V8 बेहद कुशलता से काम करता है। लेकिन पायथन के स्तर पर मेमोरी का उपभोग किया जाता है, और मेमोरी को बहुत अधिक खपत नहीं किया जाता है (मेमोरी की खपत बढ़ सकती है जब पुनरावृत्तियों की संख्या 10 से बढ़कर 100 हो जाती है, लेकिन फिर स्थिर हो जाती है)। Jsdom parser सरल पार्सिंग के लिए स्पष्ट रूप से उपयुक्त नहीं है, क्योंकि उसका ओवरहेड बहुत अधिक है। इसलिए NodeJS में HTML पार्स करने के लिए, चीयरियो सबसे अच्छा विकल्प है।

शुद्ध पायथन में पार्सर्स गति और मेमोरी खपत दोनों में विलय कर देते हैं, और परिणाम विभिन्न पृष्ठों पर दृढ़ता से कूदेंगे। लेकिन एक ही समय में वे पुनरावृत्तियों की एक अलग संख्या में व्यवहार करते हैं (क्या जीसी समान रूप से काम करता है?)

लेकिन सबसे ज्यादा लोगों ने PyPy को चौंका दिया। या तो जीसी के साथ कुछ समस्याएं, या कार्य इसके लिए उपयुक्त नहीं है, या पार्सर्स असफल थे, या मैंने कहीं गड़बड़ कर दी, लेकिन PyPy पर पार्सर्स का प्रदर्शन पुनरावृत्तियों की संख्या के साथ कम हो जाता है, और मेमोरी की खपत रैखिक रूप से बढ़ जाती है। Bsoup3 पार्सर अधिक या कम कॉपी करता है, लेकिन इसका प्रदर्शन CPython के बराबर है। यानी केवल Bsoup3 PyPy पर पार्स करने के लिए उपयुक्त है, लेकिन यह CPython पर ध्यान देने योग्य लाभ नहीं देता है।

संदर्भ

बेंचमार्क कोड माय ब्लॉग
दस्तावेज़ ऑब्जेक्ट मॉडल

अपने कार्यान्वयन भेजें! यह बहुत आसान है!

युपीडी:
अतिरिक्त पार्सर (चार्ट, CSV) के लिए परिणाम :
गोलंग (3 पीसी, सी की तुलना में तेज) (!!!)
हैस्केल (बहुत अच्छा)
जावा (ओपनजेडक, ऑरेकल-जेरे) (स्वचालित रूप से समानांतर हो जाता है, ~ 150% सीपीयू, उपयोगकर्ता सीपीयू> वास्तविक सीपीयू)
पर्ल
php + साफ
माणिक (लिबासमाइल बाइंडिंग)
डार्ट (बहुत धीमा)
मोनो (2 पीसी) (स्वचालित रूप से समानांतर, कब्जे ~ 150% सीपीयू, उपयोगकर्ता सीपीयू> वास्तविक सीपीयू)

TOP1000 एलेक्सा पर पृष्ठ आकार पर गति और स्मृति की खपत की निर्भरता का एक पूरा लेख + अध्ययन बाद में होगा (मुझे आशा है)।

बेंचमार्क HTML पार्सर