मोटर साइकिल टैंक, या REG.RU वेबसाइट के अनुवाद को टेम्पलेट से क्यों नहीं बदल सकता है :: टूलकिट से पाठ :: Xslate

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

सबसे तेज टेम्पलेट इंजन के पवित्र कंघी बनानेवाले की रेती की खोज के कठिन कार्य में हमारी पहल के इतिहास पर, दिमित्री कारसिक द्वारा एक विस्तृत रिपोर्ट में नीचे पढ़ें, जो इस समस्या को हल करने में शामिल थे:

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

टेम्प्लेट :: टूलकिट में लिखी गई अपनी वेबसाइट की गति को बढ़ाने के लिए रजिस्ट्रार REG.RU का सामना करना पड़ा और मुझे इस समस्या को हल करने का निर्देश दिया। मुझे सुखद आश्चर्य हुआ कि संभव समाधानों का विश्लेषण करने वाली कंपनी के भीतर के लोगों ने, टेम्पलेट :: टूलकिट (इसके बाद टीटी) के पूर्ण सिंटैक्स को संरक्षित करते हुए, प्रोजेक्ट को किसी अन्य टेम्पलेट इंजन, टेक्स्ट :: Xslate में स्थानांतरित करने का निर्णय लिया।

मैंने Xslate के बारे में सुना था, लेकिन इससे पहले इसका कोई कारोबार नहीं था। वेबसाइट पर बताए गए विज्ञापन के आंकड़ों के अनुसार, वह टीटी को 158 बार पछाड़ देता है, और अगर "उसने जो कहा, उसमें से कम से कम एक आधा सच है" (सी), तो यह एक उत्कृष्ट विकल्प की तरह दिखता है। और इस कारण से बहुत संदेह नहीं था - अधिकांश परियोजना सी में लिखी गई थी, और कम से कम यह मोती से भी तेज था। इसके अलावा, Xslate आंशिक रूप से TT सिंटैक्स का समर्थन करता है। कोड को देखने के बाद, यह मुझे लग रहा था कि सब कुछ "ठीक है" - कोई पूर्ण समर्थन नहीं है, शायद इसलिए कि लेखक ने टेम्पलेट इंजन पर ध्यान केंद्रित किया है, जो उन लोगों के लिए बुनियादी संकेत छोड़ रहे हैं जो इस दिशा में एक्सस्लेट का विस्तार करने में रुचि रखेंगे (परियोजना में भाग लेने के लिए एक प्रकार का निमंत्रण)। यह सब काफी आशाजनक लग रहा था, और मैंने Xslate को इस बिंदु पर समाप्त करने का निर्णय लिया कि यह ग्राहक के लिए पूर्ण या पर्याप्त रूप से TT का समर्थन करेगा, जो REG.RU और मैं खुशी से सहमत थे। सब कुछ लाभकारी प्रतीत हो रहा था - क्लाइंट को कोड 158 गुना तेजी से प्राप्त होगा, Xslate को बेहतर सिंटैक्स और नए उपयोगकर्ता प्राप्त होंगे, समुदाय को TT2 का एक उत्कृष्ट विकल्प प्राप्त होगा, और मैं, तदनुसार, लाभ और एक टोपी में एक कलम प्राप्त करेगा।

समस्याएं लगभग तुरंत शुरू हुईं। Xslate Goro Fuji (alas, alas) के लेखक ने या तो पत्र या IRC का जवाब नहीं दिया। मॉड्यूल के विस्तार के तरीके पर सहमत होने का मेरा प्रस्ताव, ताकि यह लेखक के इरादे के अनुरूप हो, वास्तव में विफल रहा है। शायद मेरे पत्र को जापानी शिष्टाचार के नियमों के अनुसार संकलित नहीं किया गया था। मैं सम्मेलनों में जापान से प्रोग्रामरों से मुठभेड़ करने के लिए हुआ था, और अगर मैं ऑन-कॉल स्माइल्स और "हैलो-हैलो" की तुलना में अधिक जीवंत संपर्क में रहने का प्रबंधन नहीं कर सका, तो ऑनलाइन शायद अभी भी अधिक कठिन है।

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

और मैंने मॉड्यूल का अध्ययन करना शुरू किया। निष्पक्षता में, यह कहने योग्य है कि कोड और एक्सस्लेट वास्तुकला दोनों महान हैं। छात्रों को उनका अध्ययन करना चाहिए, और अनुभव वाले प्रोग्रामर भी देखने में अच्छा करेंगे। Xslate को इस तथ्य के इर्द-गिर्द बनाया गया है कि टेम्प्लेटिंग इंजन मूल रूप से पाठ के आगे-पीछे घूमता है, और अनुकूलन पहले से ही उस स्तर पर शुरू हुआ था - नियमित रूप से मोती जौ के संघनन की जगह

  $ a! = $ b 

सी में फिर से लिखा गया एक ही एनालॉग है, लेकिन जितना संभव हो उतना हल्का। इसके अलावा, सभी प्रसंस्करण सी में भी किए जाते हैं: टेम्पलेट इंजन के परमाणु संचालन (उदाहरण के लिए, टीटी के संदर्भ में उपरोक्त संक्षेपण या संचालन जैसे [% IF%], [% CALL%], आदि) केवल C में नहीं लिखे गए हैं, बल्कि उस पर टेम्प्लेट फ़ाइल का लूप लिखा जाता है। इसका मतलब यह है कि मोती से प्रक्रियाओं (भले ही सी में लिखा गया हो) को कॉल करने के लिए आवश्यक घड़ी चक्र को बचाया गया था - और यह काफी महंगा ऑपरेशन है। यह चाल संभव हो गई, क्योंकि एक टेम्पलेट जो बहुत आम लग रहा है, जैसे, उदाहरण के लिए, टीटी में लिखा गया है

 [% अगर एक%]
    पाठ ए
 [% ELSE%]
    पाठ b
 [% END%] 

Xslate प्रपत्र के छद्म-कोडांतरक आदेशों में अनुवाद करता है

 .if a
 .लिटरल "टेक्स्ट ए"
 .प्रिंट # 1
 .गोतो ३
 .लिटरल "टेक्स्ट बी"
 .प्रिंट # 2
 .end

और फिर एक बाइनरी संकलित फ़ाइल में। टीटी के विपरीत, जो टेम्पलेट्स को भी संकलित करता है, लेकिन मोती कोड में, जो कुछ इस तरह दिखता है:

 साँचा :: दस्तावेज़-> नया ( 
     ब्लॉक => उप {
         ...
         eval {
             ...
             अगर ($ a) {
                $ आउटपुट। = "टेक्स्ट ए";
             } {
                $ आउटपुट। = "टेक्स्ट बी";
             }
             ...
         }
     }
 )
 ...

और फिर नियमित निकासी के साथ लोड किया गया।
लेकिन यह भी Xslate लेखक ने पर्याप्त नहीं सोचा! कोड जो व्यक्तिगत "असेंबलर" कमांड को निष्पादित करता है, जैसा कि एक व्यक्ति सोच भी नहीं सकता है (उदाहरण के लिए):

 के लिए (i = 0; मैं <opcodes.length; मैं ++) {
     opcodes.list [i] .callback ();
 }

और तथाकथित का उपयोग कर सिलना कोड :

     LABEL (noop): TXCODE_noop (aTHX_ st);  गोटो * (st-> pc-> exec_code);
     LABEL (Move_to_sb): TXCODE_move_to_sb (aTHX_ st);  गोटो * (st-> pc-> exec_code);
     LABEL (Move_from_sb): TXCODE_move_from_sb (aTHX_ st);  गोटो * (st-> pc-> exec_code);
     LABEL (save_to_lvar): TXCODE_save_to_lvar (aTHX_ st);  गोटो * (st-> pc-> exec_code);
     ...
     LABEL (अंत): TXCODE_end (aTHX_ st);

जहां ओपोकोड "अंत" का सामना करने तक गोटो के बीच निष्पादन "कूदता है"। वास्तव में, कोई अनावश्यक फ़ंक्शन कॉल नहीं हैं, यदि, उदाहरण के लिए, TXCODE_move_to_sb कोड register.a = register.b जैसा दिखता है, जो पूरे प्रोसेसर बॉडी को सैद्धांतिक रूप से प्रोसेसर कैश में फिट करने की अनुमति देता है (यह व्यावहारिक रूप से अवास्तविक है, क्योंकि टेम्प्लेट केवल सरल से मिलकर नहीं होते हैं क्रियाएँ - हर समय मोती कार्यों के लिए कॉल की आवश्यकता होती है)।

तोते की तरफ से भी सब कुछ मनोरंजक लग रहा था। व्यक्तिगत रूप से, मेरे पास मैकेनिक हैं, ये सभी एलएल / एलआर / एलएएलआर पार्सर कभी भी विशेष रूप से दिलचस्प नहीं थे, लेकिन मैं विचार का मूल्यांकन करने में सक्षम हूं। TT और Xslate दोनों छोटी स्वतंत्र भाषाएँ हैं, और न केवल निर्देशों का एक सेट (उदाहरण के लिए, Xslate पर आप इस तरह से "गोल्फ" कर सकते हैं:

  नमस्कार, <: $ lang // "पर्ल":> दुनिया! 

हालाँकि, TT ने Parse :: Yapp द्वारा निष्पादित पुरानी सिद्ध लेक्स / yacc पद्धति का उपयोग किया, जिसने मुझे व्यक्तिगत रूप से सबसे अधिक प्रभावित किया। Xslate ने अपने स्वयं के पार्सर का उपयोग किया, जो टॉप-डाउन पार्सर की तरह बनाया गया था, और जिसका मैंने पहले सामना नहीं किया था। मैं यहां विवरण में नहीं जाऊंगा, मैं केवल यह कहूंगा कि इस प्रकार के पार्सर के साथ वाक्यविन्यास का विस्तार करना मेरे अनुभव से सबसे सुखद कार्य था। मुख्य रूप से इस तथ्य के कारण कि कोड के कई हिस्से Xslate द्वारा समर्थित सभी सिंटैक्स के लिए आम थे, और हमें उनमें से प्रत्येक को भागों में अलग करना था।

हालांकि, सबसे बड़ी समस्याएं अभी तक आई थीं, रनटाइम में। जैसा कि यह निकला, रनटाइम में Xslate में केवल TT [[% CALL%] के समान एक तंत्र नहीं है, जो किसी अन्य टेम्पलेट में परिभाषित फ़ंक्शन को कॉल कर सकता है। इसके साथ मैंने पाया कि इससे कैसे निपटा जाए, कुछ हफ़्ते का खाली समय अपने छद्म असेंबलर में बिताना और उसके सिद्धांतों को समझने की कोशिश करना, ताकि अचानक कुछ टूट न जाए। यह भी पता चला कि टीटी में असममित कोष्ठक का उपयोग करने की क्षमता है, उदाहरण के लिए, [% - ...%], और Xslate पार्सर को नहीं पता कि कैसे। लेकिन सबसे बड़ी ठोकर यह थी कि TT और Xslate में बस वेरिएबल के लिए बहुत अलग स्कोप दृश्यता है, अर्थात। अगर टीटी में मैं [% foo = 'bar'%] लिखता हूं और उसके बाद चर उप-अंक सभी उपपट्टों में दिखाई देता है, तो Xslate में यह एक स्थानीय चर है।

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

इसके साथ, सब कुछ सरल हो गया - देवल :: NYTProf, एक उत्कृष्ट प्रोफाइलर (कई वर्षों के बाद देवल :: डीप्रोफ़ विशेष रूप से), एक टेम्पलेट को ट्रेस करते समय ऐसी दिलचस्प तस्वीर तैयार की गई:



तालिका एक बार फिर से पांच गुना लंबी थी, और मैंने स्पष्टता के लिए कुछ लाइनें हटा दीं, लेकिन यहां तक ​​कि एक सरसरी विश्लेषण से पता चलता है कि मुख्य भार टीटी के कारण नहीं, बल्कि स्वतंत्र रूप से उत्पन्न होता है। नतीजतन, यहां तक ​​कि अगर आप यह सुनिश्चित करते हैं कि Xslate के साथ TTs को बदलने की गति शून्य है, तो यह वांछित दो गुना वृद्धि नहीं देगा। फिर भी, पूरी तरह से खाली हाथ पीछे न हटने के लिए, मैंने चारों ओर अफरा-तफरी मचाने का फैसला किया और यही मैंने पाया:

• main_menu.inc और index.html में, मुझे एक कॉर्न धीमा कोड मिला

 [% X%]
 [% Y% के लिए]
 ... कुछ करो ...
 [% END%]
 [% END%]

जो आसानी से एक तेजी से मेल खाती है। इसके द्वारा, मुझे लगता है, पहले से ही गति को दोगुना बढ़ाना संभव है।

• फिर - टेम्पलेट :: स्लैश, टीटी का हिस्सा। यह पता चला है कि यह मुख्य संदिग्ध लंबे समय से दृढ़ता से अनुकूलित किया गया है और कहीं और जाने के लिए टेम्पलेट में नहीं है :: Stash :: XS - जाहिर है, एक समय में इसकी गति भी किसी के साथ हस्तक्षेप करती है। फिर भी, यह मोती जौ का हिस्सा था जो समस्याग्रस्त था, जिसे मैंने थोड़ा-थोड़ा काटकर 356ms से घटाकर 238ms कर दिया। एकमात्र समस्या यह है कि मेरा "कट" विशेष रूप से इस ग्राहक के लिए और इस विशेष प्रोफ़ाइल के साथ काम करता है, और सामान्य उपयोग के लिए एक पैच का कोई मतलब नहीं होगा। दूसरे शब्दों में, आप स्थानीय हैक कैसे लागू कर सकते हैं, लेकिन फिर सिस्टम प्रशासक को इसे हर बार लगाना होगा। संदिग्ध लाभ सामान्य रूप से प्राप्त किया जाता है। कौन परवाह करता है, यहाँ यह है:

 --- टेम्प्लेट-टूलकिट -२.२४ / xs / Stash.xs.0 २०१२-११-२९ २०:२६: ५४.६4०४६--kit५००
 +++ टेम्प्लेट-टूलकिट 2.24 / xs / Stash.xs 2012-11-22 23:26: 39.406594300_0100
 @@ -1198.21 +1198.7 @@
      }
 
      अगर (! Svok (RETVAL)) {
 - डीएसपी;
 - एंटर;
 - SAVETMPS;
 - पुश्कर्क (एसपी);
 - एक्सपीयूएचएस (रूट);
 - XPUSHs (पहचान);
 - पुटबैक;
 - n = call_method ("अपरिभाषित", G_SCALAR);
 - स्पागन;
 - अगर (n! = 1)
 - क्रोक ("अपरिभाषित () ने एक भी मान नहीं लौटाया \ n");
 - RETVAL = SvREFCNT_inc (POPs);
 - पुटबैक;
 - FREETMPS;
 - लेव;
 + RETVAL = newSVpv ("", 0);
      }
      अन्यथा

मोटे तौर पर, अपरिभाषित कॉल करना बहुत महंगा है, लेकिन आपको बस एक खाली स्ट्रिंग वापस करने की आवश्यकता है। लेकिन, अगर यह 60 हजार कॉल होगा, तो समय के अनुसार खर्च बढ़ेगा।

• IO :: Uncompress :: * और IO :: Compress :: *, जैसा कि यह निकला, मेमकाटेड से संबंधित है - यह डेटा को संपीड़ित करता है यदि इसका आकार वहां कुछ डिफ़ॉल्ट मेगाबाइट से अधिक है। मैंने इस विकल्प के साथ खेला, लेकिन सुधार सूक्ष्म था।

• अंत में, टेम्पलेट :: Iterator, 180,660 कॉल। मैंने इसे आंशिक रूप से XS में कॉपी किया और इसे 263 से घटाकर 7ms कर दिया, जो कुल अनुरोध का 5-7% है। परिणाम CPAN को टेम्पलेट :: Iterator :: XS के रूप में अपलोड किया गया था। यह एकमात्र ऐसी चीज है जो समुदाय को लाभ पहुंचा सकती है। यदि आपके पास टीटी पर एक मौजूदा परियोजना है, तो आप इस तरह से इस मॉड्यूल का अच्छी तरह से निर्माण कर सकते हैं

 टेम्पलेट का उपयोग करें;
 टेम्पलेट का उपयोग करें: Iterator :: XS;
 $ टेम्प्लेट :: कॉन्फिगर :: इटरेटर = 'टेम्प्लेट: इटरेटर :: एक्सएस ’;

और देखो कि यह क्या आता है।

परिणाम ऐसे थे कि वे घमंड नहीं कर सकते थे। टीटी से स्विच करने के लिए सबसे अच्छा (और क्या यह इसके लायक है या नहीं) का सवाल अभी तक मेरे लिए खुला है। इसके अलावा, यह एक असंभव निष्कर्ष बनाना असंभव है कि टीटी बहुत खराब है - किसी भी मामले में, निष्पादन की गति के मामले में, लेकिन यह सामान्य चर्चा का विषय है।

अंत में, मैं दिलचस्प कोड में तल्लीन करने के लिए और खाका :: Iterator :: XS मॉड्यूल के प्रकाशन में दृढ़ता के लिए REG.RU को धन्यवाद देना चाहता हूं - इस लेख का परिणाम है, जो मेरी पहल पर जारी होने की संभावना नहीं थी। आमतौर पर, कंपनियां स्पष्ट रूप से उस कोड को रखने में रुचि नहीं रखती हैं जो उनके आदेश को कहीं भी प्रकाशित किया गया था। इस संबंध में, REG.RU एक सुखद अपवाद था, जिसके लिए मैं मोती समुदाय की ओर से अपना आभार व्यक्त करता हूं। "