जावा - सॉकेट के साथ DataInputStream का उपयोग करके, buffered या नहीं?

Question

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

कारण मैं पूछ रहा हूं क्योंकि मुझे नहीं पता कि सॉकेट स्ट्रीम से सीधे पढ़ने के लिए कितना महंगा है (BufferedInputStream का उपयोग करते समय यह सॉकेट स्ट्रीम से केवल एक बार पढ़ेगा और फिर BufferedInputStream का उपयोग करके गुणा करें DataInputStream)।

प्राप्त डेटा आमतौर पर लगभग 20-25 बाइट्स बहुत छोटा होता है।

किसी भी उत्तर के लिए अग्रिम धन्यवाद! : डी

Answer 1

एक DataInputStream बफ़र नहीं है, इसलिए प्रत्येक एक DataInputStream वस्तु पर आपरेशन पढ़ा में एक या एक से अधिक अंतर्निहित सॉकेट धारा पर पढ़ता परिणाम के लिए जा रहा है, और कहा कि विभिन्न सिस्टम कॉल (या समतुल्य) में परिणाम सकता है ।

एक सिस्टम कॉल आम तौर पर नियमित विधि कॉल की तुलना में परिमाण के 2 से 3 ऑर्डर अधिक महंगा है। बफर्ड स्ट्रीम नियमित विधि कॉल की एक अतिरिक्त परत जोड़ने की लागत पर सिस्टम कॉल (आदर्श रूप से 1) की संख्या को कम करके काम करते हैं। आम तौर पर एक बफरर्ड स्ट्रीम का उपयोग करके एन सिस्कोल 1 सिस्कोल और एन अतिरिक्त विधि कॉल के साथ बदल जाता है। यदि एन 1 से बड़ा है, तो आप जीतते हैं।

यह इस प्रकार है कि केवल मामलों में जहां सॉकेट धारा के बीच एक BufferedInputStream डालने और DataInputStream नहीं एक जीत है कर रहे हैं:

• जब आवेदन केवल एक read...() फोन करेगा और है कि एक से संतुष्ट किया जा सकता है एकल syscall,
• जब एप्लिकेशन केवल read(byte[] ...) कॉल करता है, या
• जब एप्लिकेशन कुछ भी नहीं पढ़ता है।

ऐसा लगता है जैसे ये आपके मामले में लागू नहीं होते हैं।

इसके अलावा, यदि वे लागू होते हैं, तो भी BufferedInputStream का उपयोग करने के ऊपरी हिस्से को अपेक्षाकृत कम करने की आवश्यकता नहीं है। जब आपको बड़ी आवश्यकता हो तो BufferedInputStream का उपयोग न करने का ओवरहेड।

एक अंतिम बिंदु, डेटा की वास्तविक मात्रा (यानी संदेशों का आकार) बहुत अधिक अप्रासंगिक बफर्ड बनाम unbuffered conundrum में है। वास्तव में महत्वपूर्ण बात यह है कि डेटा पढ़ा जाता है; यानी read...() का अनुक्रम है कि आपका आवेदन करेगा।

Answer 2

सामान्य ज्ञान यह है कि व्यक्ति अंतर्निहित धारा पर पढ़ता है बहुत धीमा होता है इसलिए बफरिंग लगभग हमेशा तेज होती है। हालांकि, ऐसी छोटी संख्याओं (20-25 बाइट्स) के लिए यह हो सकता है कि बफर आवंटित करने की लागत उन व्यक्तियों को पढ़ने की लागत के समान होती है (एक बार जब आप स्मृति आवंटन और कचरा संग्रह मानते हैं)। दुर्भाग्यवश, इसका पता लगाने का एकमात्र तरीका यह जांचना और देखना है।

आप कहते हैं कि प्राप्त डेटा आमतौर पर छोटा है: आप कितनी बार बड़े संदेश की अपेक्षा करते हैं? यदि आप एक अप्रयुक्त स्ट्रीम पर कभी-कभी बड़े संदेश प्राप्त करते हैं तो यह एक महत्वपूर्ण बाधा होगी।

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