कोटलिन पार्सिंग कितनी तेजी से करता है और इससे क्या फर्क पड़ता है? JavaCC या ANTLR? क्या JetBrains स्रोत कोड उपयुक्त हैं?

तुलना कीजिए, कल्पना कीजिए और आश्चर्य कीजिए।

टीएल, डॉ

JetBrains को खींचना बहुत मुश्किल है, ANTLR प्रचार है लेकिन अप्रत्याशित रूप से धीमा है, और JavaCC लिखना बंद करने के लिए बहुत जल्दी है।

तीन अलग-अलग कार्यान्वयनों के साथ एक सरल कोटलिन फ़ाइल पार्स करना:

`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`
`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`
`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`
`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`
`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`

एक दिन ठीक धूप ...

मैंने कुछ सुविधाजनक भाषा से GLSL में एक अनुवादक बनाने का फैसला किया। यह विचार सीधे विचार में कार्यक्रम करने और "मुफ्त" आईडीई समर्थन प्राप्त करने का था - वाक्यविन्यास, डिबग और यूनिट परीक्षण। यह वास्तव में बहुत सुविधाजनक निकला।

तब से, कोटलिन का उपयोग करने का विचार बना हुआ है - आप इसमें vec3 नाम का उपयोग कर सकते हैं, यह अधिक सख्त है और आईडीई में अधिक सुविधाजनक है। इसके अलावा, यह प्रचार है। हालांकि, मेरे आंतरिक प्रबंधक के दृष्टिकोण से, ये सभी अपर्याप्त कारण हैं, यह विचार इतनी बार वापस आया कि मैंने इसे लागू करने से बस छुटकारा पाने का फैसला किया।

जावा क्यों नहीं? कोई ऑपरेटर अधिभार नहीं है, इसलिए वेक्टर अंकगणित का वाक्यविन्यास उस गेम में देखने के लिए आपके द्वारा उपयोग किए जाने वाले उपयोग से बहुत अलग होगा।

जेटब्रेन्स

JetBrains के लोगों ने अपने संकलक कोड को गितुब में अपलोड किया। इसका उपयोग कैसे करें, आप यहां और यहां देख सकते हैं ।

सबसे पहले मैंने विश्लेषक के साथ उनके पार्सर का उपयोग किया, क्योंकि किसी अन्य भाषा में अनुवाद करने के लिए, आपको यह जानने की जरूरत है कि वेरिएबल val x = vec3() को स्पष्ट रूप से निर्दिष्ट किए बिना किस प्रकार का है। यहां पाठक के लिए प्रकार स्पष्ट है, लेकिन एएसटी में यह जानकारी प्राप्त करना इतना आसान नहीं है, खासकर जब एक अन्य चर दाईं ओर, या एक फ़ंक्शन कॉल है।

यहाँ मैं निराश था। एक आदिम फ़ाइल पर पार्सर का पहला लॉन्च 3s (THREE SECONDS) लेता है।

Kotlin JetBrains parser
first call elapsed : 3254.482ms
min time in next 10 calls: 70.071ms
min time in next 100 calls: 29.973ms
min time in next 1000 calls: 16.655ms
Whole time for 1111 calls: 40.888756 seconds

ऐसे समय में निम्नलिखित स्पष्ट असुविधाएँ होती हैं:

क्योंकि यह एक गेम या एप्लिकेशन लॉन्च करने के लिए तीन सेकंड से अधिक है।
विकास के दौरान, मैं एक गर्म शेडर अधिभार का उपयोग करता हूं और कोड बदलने के तुरंत बाद परिणाम देखता हूं।
मैं अक्सर एप्लिकेशन को पुनरारंभ करता हूं और मुझे खुशी है कि यह काफी तेजी से शुरू होता है (एक या दो)।

प्लस को पार्सर को गर्म करने के लिए तीन सेकंड - यह अस्वीकार्य है। बेशक, यह तुरंत स्पष्ट हो गया कि बाद की कॉल के दौरान, पार्सिंग का समय 50ms और यहां तक कि 20ms तक चला जाता है, जो अभिव्यक्ति से असुविधा 2 नंबर को हटा देता है। लेकिन बाकी दो कहीं नहीं जाते। इसके अलावा, 50ms प्रति फ़ाइल प्लस 2500ms प्रति 50 फाइलें (एक shader 1-2 फाइलें है)। क्या होगा अगर यह Android है? (यहां हम केवल समय के बारे में बात कर रहे हैं।)

उल्लेखनीय जेआईटी का पागल काम है। एक साधारण फ़ाइल के लिए पार्सिंग का समय 70ms से 16ms तक हो जाता है। जिसका अर्थ है, सबसे पहले, JIT स्वयं संसाधनों का उपभोग करता है, और दूसरी बात, एक अलग JVM पर परिणाम बहुत भिन्न हो सकते हैं।

यह पता लगाने की कोशिश में कि ये नंबर कहाँ से आए थे, एक विकल्प था - बिना विश्लेषक के उनके पार्सर का उपयोग करें। आखिरकार, मुझे केवल प्रकारों को व्यवस्थित करने की आवश्यकता है और यह अपेक्षाकृत आसानी से किया जा सकता है, जबकि जेटब्रेन विश्लेषक कुछ अधिक जटिल करता है और बहुत अधिक जानकारी एकत्र करता है। और फिर स्टार्ट-अप का समय आधे से कम हो जाता है (लेकिन लगभग एक सेकंड और आधा वैसे भी सभ्य होता है), और बाद की कॉल का समय पहले से कहीं अधिक दिलचस्प है - पहले दस में 8ms से लेकर 0.9 तक हजार में कहीं।

Kotlin JetBrains parser (without analyzer)

()
first call elapsed : 1423.731ms
min time in next 10 calls: 8.275ms
min time in next 100 calls: 2.323ms
min time in next 1000 calls: 0.974ms
Whole time for 1111 calls: 3.6884801 seconds

()
first call elapsed : 1423.731ms
min time in next 10 calls: 8.275ms
min time in next 100 calls: 2.323ms
min time in next 1000 calls: 0.974ms
Whole time for 1111 calls: 3.6884801 seconds

मुझे सिर्फ इतनी संख्याएँ जमा करनी थीं। पहले शेड्स को लोड करते समय पहला लॉन्च समय महत्वपूर्ण है। यह महत्वपूर्ण है, क्योंकि यहां आप उपयोगकर्ता को विचलित नहीं कर सकते हैं, जबकि पृष्ठभूमि में शेड्स लोड होने के बाद, वह बस इंतजार करता है। रनटाइम में एक गिरावट स्वयं गतिशीलता को देखने के लिए महत्वपूर्ण है, जेआईटी कैसे काम करता है, हम कुशलतापूर्वक एक गर्म आवेदन पर लोड कैसे कर सकते हैं।

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

ANTLR

JavaCC में कोई पार्सर नहीं था, लेकिन उम्मीद के मुताबिक ANTLR पर, वहाँ ( एक , दो ) हैं।

लेकिन जो अप्रत्याशित था वह था गति। लोडिंग (पहली कॉल) के लिए 3s और बाद की कॉल के लिए शानदार 140ms। यहां, न केवल पहला लॉन्च अप्रिय रूप से लंबे समय तक रहता है, लेकिन फिर स्थिति को ठीक नहीं किया जाता है। जाहिरा तौर पर, JetBrains के लोगों ने JIT को इस तरह से अपने कोड को अनुकूलित करने की अनुमति देकर कुछ जादू किया। क्योंकि ANTLR समय के साथ अनुकूलित नहीं है।

Kotlin ANTLR parser

()
first call elapsed : 3705.101ms
min time in next 10 calls: 139.596ms
min time in next 100 calls: 138.279ms
min time in next 1000 calls: 137.20099ms
Whole time for 1111 calls: 161.90619 seconds

()
first call elapsed : 3705.101ms
min time in next 10 calls: 139.596ms
min time in next 100 calls: 138.279ms
min time in next 1000 calls: 137.20099ms
Whole time for 1111 calls: 161.90619 seconds

JavaCC

सामान्य तौर पर, हम ANTLR की सेवाओं से इनकार करते हुए आश्चर्यचकित हैं। पार्सिंग को इतना लंबा होना जरूरी नहीं है! कोटलिन के व्याकरण में कोई ब्रह्मांडीय अस्पष्टता नहीं है, और मैंने इसे व्यावहारिक रूप से खाली फाइलों पर जांचा। तो, पुराने जावासीसी को उजागर करने का समय है, अपनी आस्तीन ऊपर रोल करें, और फिर भी "इसे स्वयं करें और कैसे करें।"

इस बार संख्या उम्मीद के मुताबिक निकली, हालांकि विकल्पों के साथ तुलना में - अप्रत्याशित रूप से सुखद।

Kotlin JavaCC parser

()
first call elapsed : 19.024ms
min time in next 10 calls: 1.952ms
min time in next 100 calls: 0.379ms
min time in next 1000 calls: 0.114ms
Whole time for 1111 calls: 0.38707677 seconds

()
first call elapsed : 19.024ms
min time in next 10 calls: 1.952ms
min time in next 100 calls: 0.379ms
min time in next 1000 calls: 0.114ms
Whole time for 1111 calls: 0.38707677 seconds

अपने JavaCC पार्सर के अचानक पेशेवरों
बेशक, अपने स्वयं के पार्सर लिखने के बजाय, मैं तैयार समाधान का उपयोग करना चाहूंगा। लेकिन मौजूदा लोगों के भारी नुकसान हैं:

- प्रदर्शन (नए शैडर को पढ़ते समय रुक जाना अस्वीकार्य है, साथ ही शुरुआत में तीन सेकंड वार्म-अप)
- एक विशाल कोटलिन रनटाइम, मुझे यह भी पता नहीं है कि क्या पार्सर को अंतिम उत्पाद में उपयोग करना संभव है
- वैसे, ग्रूवी के साथ मौजूदा समाधान में एक ही मुसीबत - रनटाइम स्ट्रेच

जबकि परिणामी JavaCC पार्सर है

+ उत्कृष्ट गति शुरू और प्रक्रिया दोनों में
+ केवल पार्सर के कुछ वर्ग

निष्कर्ष

`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`
`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`
`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`
`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`
`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`	`1000 () JetBrains 3254 16,6 35.3 JetBrains (w/o analyzer) 1423 0,9 35.3 ANTLR 3705 137,2 1.4 JavaCC 19 0,1 0.8`

कुछ बिंदु पर, मैंने सभी निर्भरताओं के साथ जार के आकार को देखने का फैसला किया। JetBrains अपेक्षित रूप से महान हैं, ~~लेकिन ANTLR रनटाइम अपने आकार के साथ~~ ।
अद्यतन: प्रारंभ में, मैंने 15MB लिखा, लेकिन, जैसा कि टिप्पणियों में सुझाया गया है, यदि आप antlr4 के बजाय antlr4-runtime को जोड़ते हैं, तो आकार अपेक्षित मान पर गिर जाता है। हालाँकि JavaCC parser स्वयं ANTLR से 10 गुना छोटा है (यदि आप स्वयं पार्सर्स को छोड़कर सभी कोड हटा देते हैं)।
इस तरह के रूप में जार का आकार महत्वपूर्ण है, निश्चित रूप से, सेल फोन के लिए। लेकिन यह डेस्कटॉप के लिए भी मायने रखता है, क्योंकि वास्तव में, इसका मतलब अतिरिक्त कोड की मात्रा है जिसमें बग हो सकते हैं, जिसे आईडीई को इंडेक्स करना चाहिए, जो वास्तव में, पहले लोड की गति और वार्मिंग की गति को प्रभावित करता है। इसके अलावा, जटिल कोड के लिए, दूसरी भाषा में अनुवाद करने की बहुत कम उम्मीद है।
मैं आपसे किलोबाइट गिनने का आग्रह नहीं करता हूं और मैं प्रोग्रामर के समय और सुविधा की सराहना करता हूं, लेकिन फिर भी यह बचत के बारे में सोचने लायक है, क्योंकि इस तरह से परियोजनाएं अनाड़ी और बनाए रखना मुश्किल हो जाता है।

ANTLR और JavaCC के बारे में कुछ शब्द

ANTLR की एक गंभीर विशेषता व्याकरण और कोड का अलग होना है। अच्छा होगा अगर इसे इतना महंगा न देना पड़े। हां, और यह केवल "व्याकरण के सीरियल डेवलपर्स" के लिए मायने रखता है, और अंतिम उत्पादों के लिए यह इतना महत्वपूर्ण नहीं है, क्योंकि यहां तक कि मौजूदा व्याकरण को अभी भी अपना कोड लिखने के लिए समाप्त होना होगा। इसके अलावा, अगर हम पैसे बचाते हैं और "थर्ड-पार्टी" व्याकरण लेते हैं - तो यह सिर्फ असुविधाजनक हो सकता है, इसे अभी भी अच्छी तरह से समझना होगा और खुद के लिए एक पेड़ में बदलना होगा। सामान्य तौर पर, जावासीसी, निश्चित रूप से, मक्खियों और कटलेट को मिलाता है, लेकिन क्या यह वास्तव में मायने रखता है और क्या यह इतना बुरा है?

ANTLR की एक और विशेषता कई लक्ष्य प्लेटफ़ॉर्म हैं। लेकिन यहां आप दूसरी तरफ से देख सकते हैं - जावासीसी के तहत कोड बहुत सरल है। और इसका बहुत ही सरल ... प्रसारण! अपने कस्टम कोड के साथ - कम से कम C # में, कम से कम JS में।

पुनश्च

सभी कोड यहाँ github.com/kravchik/yast है

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

जावासीसी पार्सर में अभी तक सभी व्याकरण नहीं हैं, 10 प्रतिशत शेष हैं। लेकिन ऐसा नहीं लगता है कि वे प्रदर्शन को प्रभावित कर सकते हैं - मैंने नियमों को जोड़ा गया गति की जांच की, और यह बिल्कुल नहीं बदला। इसके अतिरिक्त, मैंने पहले ही अपनी आवश्यकता से बहुत अधिक काम कर लिया है और प्रक्रिया में मिले अप्रत्याशित परिणाम को साझा करने का प्रयास कर रहा हूं।

संकलन कोटलिन: जेटब्रेन्स वीएस एएनटीएलआर वीएस जावासीसी