2009-02-22 9 views
37

psyco पायथन कोड को अनुकूलित करने में काफी मददगार प्रतीत होता है, और यह एक बहुत ही घुसपैठ तरीके से करता है।पाइथन कोड के लिए हमेशा साइको का उपयोग क्यों नहीं करते?

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

क्या आपके पास इसके साथ कोई नकारात्मक अनुभव है? अब तक मेरा सबसे नकारात्मक अनुभव यह था कि उसने अपना कोड केवल 15% बढ़ा दिया। आमतौर पर यह बेहतर है।

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

उत्तर

20

1) स्मृति उत्तर ओवरहेड मुख्य उत्तर है, जैसा कि अन्य उत्तरों में वर्णित है। आप संकलन लागत का भी भुगतान करते हैं, जो कि आप चुनिंदा नहीं हैं, जो निषिद्ध हो सकते हैं। user reference से:

सब कुछ संकलित करना अक्सर मध्यम या बड़े आकार के अनुप्रयोगों के लिए अधिक होता है। बहुत अधिक संकलन करने की कमी संकलन में बिताए गए समय के साथ-साथ इस प्रक्रिया का उपभोग करने वाली स्मृति की मात्रा भी होती है। यह रखने के लिए एक सूक्ष्म संतुलन है।

2) प्रदर्शन वास्तव में साइको संकलन द्वारा नुकसान पहुंचाया जा सकता है। फिर उपयोगकर्ता पुस्तिका ("known bugs" अनुभाग) से: परिस्थितियाँ होती हैं जिनमें Psyco यह तेजी के बजाय कोड को धीमा कर देती:

वहाँ भी प्रदर्शन कीड़े हैं। यह संभावित कारणों की एक पूरी सूची बनाने के लिए कठिन है, लेकिन यहाँ कुछ सामान्य निम्न हैं:

  • निर्मित map और filter कार्यों से परहेज और सूची समझ के द्वारा बदल दिया जाना चाहिए। उदाहरण के लिए, map(lambda x: x*x, lst) को अधिक पठनीय लेकिन अधिक हालिया वाक्यविन्यास [x*x for x in lst] द्वारा प्रतिस्थापित किया जाना चाहिए।
  • नियमित अभिव्यक्तियों का संकलन साइको से लाभ नहीं लग रहा है। (नियमित अभिव्यक्तियों का निष्पादन अप्रभावित है, क्योंकि यह सी कोड है।) इस मॉड्यूल पर साइको को सक्षम न करें; यदि आवश्यक हो, तो इसे स्पष्ट रूप से अक्षम करें, उदा। psyco.cannotcompile(re.compile) पर कॉल करके।

3) अंत में, वहाँ कुछ अपेक्षाकृत अस्पष्ट स्थितियों में, जहां Psyco का उपयोग कर वास्तव में बग प्रस्तुत करेंगे। उनमें से कुछ listed here हैं।

5

pyglet का उपयोग करते समय मैंने पाया कि मैं अपने ऐप गैर कार्यात्मक बनाने के बिना पूरे एप्लिकेशन पर psyco उपयोग नहीं कर सका। मैं इसे गणित-भारी कोड के छोटे वर्गों में उपयोग कर सकता हूं, लेकिन यह आवश्यक नहीं था, इसलिए मैंने परेशान नहीं किया।

इसके अलावा, psyco (जैसे, साथ ही, उन्हें गैर psyco संस्करण से बिल्कुल बदल नहीं) मेरी रूपरेखा परिणामों के साथ अजीब बातें किया गया है। मुझे संदेह है कि यह प्रोफाइलिंग कोड के साथ अच्छा नहीं खेलता है।

मैं सिर्फ सच में उसका उपयोग नहीं करते जब तक कि मैं वास्तव में गति चाहते हैं, जो सभी कि अक्सर नहीं है। मेरी प्राथमिकता एल्गोरिदम अनुकूलन है, जो आमतौर पर nicer speedups में परिणाम देता है।

4

यह भी निर्भर करता है कि आपकी बाधा कहां है। मैं ज्यादातर वेब ऐप कर रहा हूं और वहां बाधाएं शायद अधिक आईओ और डेटाबेस हैं। तो आपको पता होना चाहिए कि अनुकूलित करना कहां है।

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

+1

+1 ढूंढने का समय है: आपको यह जानना होगा कि अनुकूलित करना कहां है। यदि आपके पास गलत एल्गोरिदम साइको बहुत मदद नहीं करेगा। यदि आपके पास सही एल्गोरिदम है, तो साइको कोई फर्क नहीं पड़ता। –

6

Psyco वर्तमान में स्मृति का एक बहुत उपयोग करता है। यह केवल इंटेल 386-संगत प्रोसेसर (किसी भी ओएस के तहत) पर चलता है। कुछ सूक्ष्म अर्थपूर्ण मतभेद (यानी बग) पायथन काम करता है; वे अधिकांश कार्यक्रमों में स्पष्ट नहीं होना चाहिए।

caveats section भी देखें। एक कठिन उदाहरण के लिए, मैंने देखा कि चीता से उत्पन्न टेम्पलेट्स और डीबी I/O के साथ मेरा वेब ऐप कोई सराहनीय गति प्राप्त नहीं हुआ है।

1

काफी सरल: "क्योंकि कोड पहले से ही पर्याप्त तेज़ी से चलता है"।

3

एक कुछ जादुई गोली पर भरोसा कभी नहीं करना चाहिए अपनी समस्याओं को ठीक करने। धीमी गति से प्रोग्राम बनाने के लिए साइको का उपयोग करना आमतौर पर आवश्यक नहीं होता है। खराब एल्गोरिदम को फिर से लिखा जा सकता है, और भागों को गति की आवश्यकता किसी अन्य भाषा में लिखी जा सकती है। बेशक, आपका प्रश्न पूछता है कि हम इसे किसी भी तरह से गति बढ़ाने के लिए क्यों नहीं उपयोग करते हैं, और जब आप psyco का उपयोग करते हैं तो थोड़ा अधिक ओवरहेड होता है। साइको स्मृति का उपयोग करता है, और उन दो पंक्तियों को क्रमशः महसूस करते हैं जैसे ओवरहेड। मेरे व्यक्तिगत कारण के कारण मैं साइको का उपयोग क्यों नहीं करता, ऐसा इसलिए है क्योंकि यह x86_64 का समर्थन नहीं करता है, जिसे मैं नए और आने वाले आर्किटेक्चर के रूप में देखता हूं (विशेष रूप से 2038 के साथ जल्दी या बाद में)। मेरा विकल्प खराब है, लेकिन मैं पूरी तरह से उस के शौकीन नहीं हूँ।

2

अन्य चीजों के एक जोड़े:

  1. यह बहुत सक्रिय रूप से बनाए रखने के लिए प्रतीत नहीं होता।
  2. यह एक स्मृति हॉग हो सकता है।
3

साइको मर चुका है और लंबे समय तक बनाए रखा नहीं है। अब एक और

संबंधित मुद्दे