हम एक बैंक में एक बड़ा वित्तीय आवेदन विकसित कर रहे हैं। यह वास्तव में खराब कोड की 150k लाइनों के रूप में शुरू हुआ। 1 महीने पहले, यह आधा से थोड़ा अधिक था, लेकिन निष्पादन योग्य का आकार अभी भी बड़ा था। मुझे उम्मीद थी कि चूंकि हम कोड को और अधिक पठनीय बना रहे थे, लेकिन टेम्पलेट कोड अभी भी बहुत सारे ऑब्जेक्ट कोड उत्पन्न कर रहा था, हम अपने प्रयास के साथ और अधिक कुशल थे।विशाल निष्पादन योग्य, क्यों?
एप्लिकेशन लगभग 5 साझा वस्तुओं और मुख्य में टूटा हुआ है। बड़ी साझा वस्तुओं में से एक 40 एमबी था और कोड कम होने के बावजूद 50 तक बढ़ गया।
मुझे पूरी तरह से आश्चर्य नहीं हुआ कि कोड बढ़ने लगा, क्योंकि आखिरकार हम कुछ कार्यक्षमता जोड़ रहे हैं। लेकिन मुझे आश्चर्य हुआ कि यह 20% तक बढ़ गया। निश्चित रूप से कोई भी 20% कोड लिखने के करीब नहीं आया, इसलिए मेरे लिए कल्पना करना मुश्किल है कि यह कितना बड़ा हुआ। यह मॉड्यूल मेरे लिए विश्लेषण करने के लिए कठिन है, लेकिन शुक्रवार को, मेरे पास एक नया डेटापॉइंट है जो कुछ प्रकाश डालता है।
एसओएपी सर्वरों के लिए शायद 10 फ़ीड्स हैं। कोड बुरी तरह से स्वत: उत्पन्न है।
#include <boost/shared_ptr.hpp>
#include <xercesstuff...>
class ParserService1 {
public:
void parse() {
try {
Service1ContentHandler*p = new Service1ContentHandler(...);
parser->setContentHandler(p);
parser->parser();
} catch (SAX ...) {
...
}
}
};
इन कक्षाओं पूरी तरह से अनावश्यक थे, एक भी समारोह काम करता है: प्रत्येक सेवा की तरह कुछ बिल्कुल वैसा ही कोड के साथ एक पार्सर वर्ग था। प्रत्येक कंटेंट हैंडलर क्लास को उसी 7 या 8 चर के साथ स्वत: उत्पन्न किया गया था, जिसे मैं विरासत के साथ साझा करने में सक्षम था।
तो मैं पार्सर कक्षाओं और कोड से हटाए जाने पर कोड के आकार को नीचे जाने की उम्मीद कर रहा था। लेकिन केवल 10 सेवाओं के साथ, मैं 38 एमबी से 36 एमबी तक गिरने की उम्मीद नहीं कर रहा था। यह प्रतीकों की एक अपमानजनक मात्रा है।
एकमात्र चीज जिसे मैं सोच सकता हूं वह यह है कि प्रत्येक पार्सर में boost :: shared_ptr, कुछ Xerces पार्सर सामान शामिल थे, और किसी भी तरह, कंपाइलर और लिंकर प्रत्येक फ़ाइल के लिए बार-बार उन सभी प्रतीकों को संग्रहीत कर रहे हैं। मैं किसी भी मामले में पता लगाने के लिए उत्सुक हूँ।
तो, क्या कोई सुझाव दे सकता है कि मैं इस बारे में क्या सोचूंगा कि इस तरह के एक साधारण संशोधन का इतना प्रभाव क्यों होना चाहिए? मैं अंदरूनी प्रतीकों को देखने के लिए मॉड्यूल पर एनएम का उपयोग कर सकता हूं, लेकिन यह एक दर्दनाक, भारी मात्रा में अर्द्ध-पठनीय सामान उत्पन्न करने जा रहा है।
इसके अलावा, जब एक सहयोगी ने मेरी नई लाइब्रेरी के साथ अपना कोड चलाया, तो उपयोगकर्ता का समय 1m55 सेकेंड से 1m25 सेकेंड तक चला गया। वास्तविक समय अत्यधिक परिवर्तनीय है, क्योंकि हम धीमी एसओएपी सर्वरों पर इंतजार कर रहे हैं (आईएमएचओ, एसओएपी कॉरबा के लिए अविश्वसनीय रूप से खराब प्रतिस्थापन है ...) लेकिन सीपीयू का समय काफी स्थिर है। मुझे कोड आकार को कम करने से थोड़ा सा बढ़ावा मिलेगा, लेकिन नीचे की रेखा भारी मेमोरी वाले सर्वर पर है, मैं वास्तव में हैरान था कि गति इतनी प्रभावित हुई थी, क्योंकि मैंने आर्किटेक्चर को नहीं बदला एक्सएमएल प्रसंस्करण खुद।
मैं इसे मंगलवार को और अधिक लेने जा रहा हूं, और उम्मीद है कि अधिक जानकारी प्राप्त होगी, लेकिन अगर किसी को यह पता चल जाए कि मैं इसे कितना सुधार प्राप्त कर सकता हूं, तो मुझे जानना अच्छा लगेगा।
अद्यतन: मैंने सत्यापित किया कि वास्तव में, कार्य में डिबगिंग प्रतीक होने पर रन टाइम को बदलना प्रतीत नहीं होता है। मैंने ऐसा एक हेडर फ़ाइल बनाकर किया जिसमें बहुत सारी चीज़ें शामिल थीं, जिनमें से दो प्रभाव भी शामिल थे: साझा पॉइंटर्स और कुछ xerces XML पार्सर को बढ़ावा दें। ऐसा कोई रनटाइम प्रदर्शन हिट नहीं होता है (मैंने जांच की क्योंकि दो उत्तरों के बीच मतभेद थे)। हालांकि, मैंने यह भी सत्यापित किया है कि हेडर फाइलों सहित प्रत्येक उदाहरण के लिए डिबगिंग प्रतीक बनाता है, भले ही पट्टी बाइनरी आकार अपरिवर्तित हो। इसलिए यदि आप किसी दिए गए फ़ाइल को शामिल करते हैं, भले ही आप इसका उपयोग भी न करें, फिर भी उस ऑब्जेक्ट में एक निश्चित संख्या में प्रतीकों का ऑब्जेक्ट किया गया है जो लिंक समय पर एक साथ नहीं जुड़ा हुआ है, भले ही वे संभवतः समान हैं।
मेरे कोड लगता है:
#include "includetorture.h"
void f1()
{
f2(); // call the function in the next file
}
आकार मेरी विशेष के साथ 100k के बारे में प्रति स्रोत फ़ाइल था फ़ाइलों में शामिल हैं। संभवतः, अगर मैंने और अधिक शामिल किया था, तो यह अधिक होगा। इसमें कुल निष्पादन योग्य ~ 600k था, लगभग 9 के बिना। मैंने सत्यापित किया कि विकास सहित फाइलों की संख्या के साथ रैखिक है, लेकिन पट्टी कोड समान आकार है, जैसा कि यह होना चाहिए।
स्पष्ट रूप से मैं सोच रहा था कि यह प्रदर्शन लाभ का कारण था। मुझे लगता है कि मैंने अभी इसके लिए जिम्मेदार ठहराया है। भले ही मैंने बहुत अधिक कोड नहीं हटाया, मैंने बहुत बड़ी एक्सएमएल स्ट्रिंग प्रसंस्करण को सुव्यवस्थित किया, और कोड को कोड के माध्यम से काफी कम कर दिया, और यह संभवतः कारण है।
मैग्नस संपादित करने के लिए धन्यवाद! – Dov
अपने शीर्षक में आप डिबगिंग प्रतीकों का उल्लेख करते हैं, लेकिन आप अपनी बाकी पोस्ट में नहीं हैं। क्या मैं कुछ भूल रहा हूँ? – Bart
@ बार्ट ब्लॉउट एक्जिक्यूटिव में सभी डिबगिंग प्रतीकों की वजह से है। यदि आप पुस्तकालयों को पट्टी करते हैं, तो कोड आकार का लगभग 10% है। – Dov