बहुत कम संख्या में सॉकेट्स के लिए (आपके हार्डवेयर के आधार पर भिन्न होता है, लेकिन निश्चित रूप से हम 10 या उससे कम के ऑर्डर पर कुछ के बारे में बात कर रहे हैं), चयन स्मृति उपयोग और रनटाइम गति में एपोल को हरा सकता है। बेशक, इतनी कम संख्या में सॉकेट्स के लिए, दोनों तंत्र इतने तेज हैं कि आप वास्तव में इस अंतर के बारे में परवाह नहीं करते हैं।
एक स्पष्टीकरण, यद्यपि। दोनों का चयन करें और epoll पैमाने पर रैखिक। हालांकि, एक बड़ा अंतर यह है कि यूजर्स-फेसिंग एपीआई में जटिलताएं होती हैं जो विभिन्न चीजों पर आधारित होती हैं। selectकॉल की लागत मोटे तौर पर उस उच्चतम संख्या फ़ाइल डिस्क्रिप्टर के मान के साथ जाती है जिसे आप इसे पास करते हैं। यदि आप एक एकल fd, 100 पर चयन करते हैं, तो वह लगभग एक ही बार में दोगुना महंगा है, एक ही fd, 50 पर चयन करना। उच्चतम से नीचे अधिक fds जोड़ना बहुत मुक्त नहीं है, इसलिए यह अभ्यास की तुलना में थोड़ा अधिक जटिल है, लेकिन यह अधिकांश कार्यान्वयन के लिए एक अच्छा पहला सन्निकटन है।
एपोल की लागत फ़ाइल डिस्क्रिप्टर की संख्या के करीब है जो वास्तव में उन पर घटनाएं हैं। यदि आप 200 फ़ाइल डिस्क्रिप्टर की निगरानी कर रहे हैं, लेकिन उनमें से केवल 100 में उन पर ईवेंट हैं, तो आप (केवल मोटे तौर पर) केवल उन 100 सक्रिय फ़ाइल डिस्क्रिप्टर के लिए भुगतान कर रहे हैं। यह वह जगह है जहां एपोल अपने प्रमुख लाभों में से एक का चयन करने की पेशकश करता है। यदि आपके पास एक हजार ग्राहक हैं जो ज्यादातर बेकार हैं, तो जब आप चयन करते हैं तो आप अभी भी उनमें से सभी एक हजार का भुगतान कर रहे हैं। हालाँकि, एपोल के साथ, ऐसा लगता है कि आपको केवल कुछ ही मिला है - आप केवल उन लोगों के लिए भुगतान कर रहे हैं जो किसी भी समय सक्रिय हैं।
इसका मतलब यह है कि एपोल अधिकांश वर्कलोड के लिए कम सीपीयू का उपयोग करेगा। जहाँ तक मेमोरी उपयोग की बात है, यह एक टॉस अप का एक सा है। selectअत्यधिक कॉम्पैक्ट तरीके से (एक बिट प्रति फ़ाइल डिस्क्रिप्टर) सभी आवश्यक जानकारी का प्रतिनिधित्व करने का प्रबंधन करता है। और FD_SETSIZE (आमतौर पर 1024) की सीमा पर आप कितने फ़ाइल डिस्क्रिप्टर का उपयोग कर सकते हैं selectइसका मतलब यह है कि आप कभी भी उन तीन fd सेटों के लिए 128 बाइट्स से अधिक खर्च नहीं करेंगे जिनका आप उपयोग कर सकते हैंselect(पढ़ें, लिखना, अपवाद)। उन 384 बाइट्स मैक्स की तुलना में, एपोल एक सुअर की तरह है। प्रत्येक फ़ाइल विवरणक बहु-बाइट संरचना द्वारा दर्शाया गया है। हालाँकि, निरपेक्ष रूप से, यह अभी भी बहुत मेमोरी का उपयोग करने वाला नहीं है। आप कुछ दर्जन किलोबाइट में फ़ाइल डिस्क्रिप्टर की एक बड़ी संख्या का प्रतिनिधित्व कर सकते हैं (लगभग 20k प्रति 1000 फ़ाइल डिस्क्रिप्टर, मुझे लगता है)। और आप इस तथ्य में भी फेंक सकते हैं कि आपको उन सभी बाइट्स के सभी 384 खर्च करने होंगे selectयदि आप केवल एक फाइल डिस्क्रिप्टर की निगरानी करना चाहते हैं, लेकिन इसका मूल्य 1024 है, तो आप जिस एपल के साथ केवल 20 बाइट्स खर्च करेंगे। फिर भी, ये सभी संख्याएँ बहुत छोटी हैं, इसलिए इससे बहुत फ़र्क नहीं पड़ता।
और वहाँ भी है कि epoll के अन्य लाभ, जो शायद आप पहले से ही जानते हैं, कि यह FD_SETSIZE फ़ाइल विवरणकों तक सीमित नहीं है। आप इसका उपयोग कर सकते हैं कि आपके पास जितने फ़ाइल डिस्क्रिप्टर हैं, उतने मॉनिटर करने के लिए। और यदि आपके पास केवल एक फ़ाइल डिस्क्रिप्टर है, लेकिन इसका मान FD_SETSIZE से अधिक है, तो एपोल उसके साथ भी काम करता है, लेकिन selectऐसा नहीं करता है।
बेतरतीब ढंग से, मैंने हाल ही epollमें selectया की तुलना में एक मामूली खामी की खोज की है poll। जबकि इन तीन एपीआई में से कोई भी सामान्य फ़ाइलों (अर्थात, फ़ाइल सिस्टम पर फ़ाइलें) का समर्थन नहीं करता है , selectऔर pollइस तरह के विवरणों को हमेशा पठनीय और हमेशा लिखने योग्य के रूप में रिपोर्टिंग के रूप में समर्थन की कमी पेश करता है। यह उन्हें किसी भी प्रकार के गैर-अवरुद्ध फाइलसिस्टम I / O के लिए अनुपयुक्त बनाता है, एक प्रोग्राम जो फाइल सिस्टम से फाइल डिस्क्रिप्टर का उपयोग करने selectया pollकरने के लिए होता है, कम से कम काम करना जारी रखेगा (या यदि यह विफल हो जाता है, तो यह नहीं होगा क्योंकि की selectया poll), यह यद्यपि शायद सबसे अच्छा प्रदर्शन के साथ नहीं।
दूसरी ओर, इस तरह के एक फ़ाइल डिस्क्रिप्टर की निगरानी करने के लिए कहा जाने पर, epollएक त्रुटि ( EPERM, जाहिर है) के साथ तेजी से विफल हो जाएगा । कड़े शब्दों में, यह शायद ही गलत है। यह स्पष्ट रूप से समर्थन की कमी का संकेत दे रहा है। आम तौर पर मैं स्पष्ट विफलता की स्थिति की सराहना करता हूं, लेकिन यह एक अनैच्छिक है (जहां तक मैं बता सकता हूं) और एक पूरी तरह से टूटे हुए आवेदन में परिणाम देता है, बजाय एक जो केवल संभावित अपमानित प्रदर्शन के साथ संचालित होता है।
व्यवहार में, मैंने देखा है कि यह एकमात्र स्थान है, जब stdio के साथ बातचीत होती है। एक उपयोगकर्ता एक सामान्य फ़ाइल के लिए / से stdout रीडायरेक्ट या कर सकता है। जबकि पहले स्टडिन और स्टडआउट एक पाइप होते थे - जो एपोल द्वारा ठीक-ठीक समर्थित होते थे - फिर यह एक सामान्य फ़ाइल बन जाती है और एपोल ऐप को तोड़ते हुए जोर से विफल हो जाती है।
pollपूर्णता के व्यवहार के बारे में स्पष्ट होने पर विचार करें ?