2012-08-16 7 views
5

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

+1

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

+0

कई सुपर-कूल एल्गोरिदम को अपनी एसिम्प्टोटिक जटिलता साबित करने के लिए परिष्कृत तकनीकों की आवश्यकता होती है। अकेले कोड से ऐसा करना सभी व्यावहारिक उद्देश्यों के लिए असंभव है। –

उत्तर

5

अगर इस तरह के एक उपकरण मौजूद है मैं नहीं जानता, लेकिन मैं दोनों अपनी व्यवहार्यता और इसकी उपयोगिता पर संदेह:

  • सामान्य मामले में इस तरह के एक उपकरण की व्यवहार्यता के लिए Halting problem पर एक नज़र है, जो आप जो पूछ रहे हैं उसका एक महत्वपूर्ण हिस्सा है और undecidable साबित हुआ है।

  • इस तरह के एक उपकरण की उपयोगिता के लिए, मुझे विश्वास है कि अपने आप ही स्थिर कोड विश्लेषण बेकार है, क्योंकि एक प्रणाली के प्रदर्शन का एक महत्वपूर्ण हिस्सा अपने उपयोग प्रतिमानों है, यानी अपने इनपुट पर पर निर्भर करता है।

    एक कारण है कि रनटाइम पर बेंचमार्किंग सिस्टम भी सीधे आगे नहीं है; कुछ मामलों में वही सॉफ्टवेयर आश्चर्यजनक रूप से तेज़ हो सकता है और दूसरों में चौंकाने वाला धीमा हो सकता है।

यानी, several tools for code complexity analysis रहे हैं, लेकिन वे मीट्रिक संरचनात्मक जटिलता है, जो गुणवत्ता और प्रदर्शन से रख-रखाव के लिए और अधिक संबंधित है पर ध्यान केंद्रित।

1

लूप की संख्या के लिए, यदि/elses आप चक्रीय जटिलता मीट्रिक को नियोजित कर सकते हैं। इसकी गणना करने के लिए उपकरण हैं। उदाहरण के लिए, JavaNCSS। अन्य चीजों के बारे में, आपको यह तय करना चाहिए कि आप वास्तव में क्या रुचि रखते हैं। software metrics बहुत सारे हैं और उनमें से कुछ आपके लिए उपयुक्त हो सकते हैं। यदि नहीं, तो आप अपना आविष्कार कर सकते हैं और उन्हें लागू कर सकते हैं। कहें, PMD - विभिन्न मीट्रिक एकत्र करने के लिए एक और लोकप्रिय टूल - आपको अपने नियम लिखने की अनुमति देता है।

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

+0

धन्यवाद दोस्तों! हां, मुझे पता है कि संरचनात्मक जटिलता मुझे वास्तविक लागत नहीं देगी लेकिन मैं वहां से शुरू करना चाहता हूं और फिर देख सकता हूं कि मुझे और क्या ध्यान रखना है। मैं इन लिंक का अध्ययन करूंगा और देख सकता हूं कि मैं क्या कर सकता हूं। – kepha

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