मुख्य निष्कर्ष
- Go भाषा हमेशा तेज़ नहीं होती। बल्कि कई बार JS runtime उससे तेज़ हो सकता है।
- Go अपनी सादगी और दक्षता के लिए जानी जाती है, लेकिन वास्तविक environment में इसका performance उम्मीद से कम हो सकता है।
- खासकर जहाँ database I/O ज़्यादा हो, वहाँ Bun जैसे JavaScript runtime की तुलना में इसका performance कमज़ोर पड़ सकता है.
benchmark परिणाम
- Go में request throughput ज़्यादा और memory usage कम था, लेकिन CPU usage 2~3 गुना अधिक था।
- लेकिन DB I/O वाले real-world environment में Bun (Elysia framework और MySQL2 library का संयोजन) ने अधिक स्थिर और efficient performance दिखाया।
- standard HTTP router का performance कम था, इसलिए Fiber framework पर स्विच करने के बाद Bun जैसी response speed मिली। (Go standard HTTP Router का इस्तेमाल मत कीजिए!)
यह benchmark करते समय Go के जो फ़ायदे लगे
- विभिन्न primitive types और type safety मिलना।
- single binary deployment: एक साधारण executable file से deploy किया जा सकता है, runtime dependency हट जाती है।
- goroutines: parallel processing को efficiently support करती हैं, और सही उपयोग पर hardware performance को अधिकतम किया जा सकता है।
इस benchmark से महसूस हुई सीमाएँ और सुधार की गुंजाइश
- MySQL driver के performance पर संदेह: Go का go-mysql-driver स्थिर तो है, लेकिन धीमा है, और JavaScript के mysql2 की तुलना में performance कमज़ोर लगता है। (बेशक, हो सकता है मैं ही ग़लत सोच रहा हूँ)
- जिन कामों में DB connection नहीं होता, उनमें Go बेहतर performance दिखाता है। शायद यह स्वाभाविक भी है।
- HTTP router का कमज़ोर performance: अपनी मानसिक शांति के लिए Fiber या किसी दूसरे framework का इस्तेमाल कीजिए!
performance से संतुष्ट न होने के बावजूद Go का उपयोग जारी रखने की वजह
- Go की type safety, single binary deployment, और goroutines की parallel processing performance डेवलपर के रूप में काफ़ी आकर्षक हैं। TypeScript से पूरी न होने वाली types, और
npm install के बिना single binary file deployment — यही इसकी बहुत बड़ी merit लगी।
- अतिरिक्त performance optimization की संभावनाएँ देखकर मैंने Go को और सीखते हुए इस्तेमाल जारी रखने का फ़ैसला किया।
डेवलपर्स के लिए संदेश
- हर भाषा और तकनीक की अपनी ताकतें और कमज़ोरियाँ होती हैं। मेरा मानना है कि Go भाषा भी इससे अलग नहीं है।
- Go के performance से निराश होने के बजाय, उसके फ़ायदों का सही उपयोग करना और performance की सीमाओं को पार करने के तरीके खोजते रहना बेहतर होगा।
- Go इस्तेमाल करने वाले डेवलपर्स के साथ यह विश्लेषणात्मक नतीजा साझा करने के लिए ही यह लेख लिखा गया है।
16 टिप्पणियां
पूरी तरह अलग बात है, लेकिन IBM Plex Sans KR फ़ॉन्ट बहुत खूबसूरत है।
मुझे भी वह फ़ॉन्ट सच में बहुत पसंद आया था, इसलिए मैंने उसे इस्तेमाल किया, लेकिन बस एक ही कमी लगी कि कम resolution वाले monitor पर देखने पर वह खास सुंदर नहीं लगता। haha 5K monitor पर देखें to सच में बहुत सुंदर लगता है!
मुझे लगता है कि किसी चीज़ की आलोचना करते समय वास्तव में बहुत सावधान रहना चाहिए।
यह भी अस्पष्ट है कि यह भाषा-स्तर का मुद्दा है, किसी विशेष लाइब्रेरी का मुद्दा है, या कोड का मुद्दा है; और जब ऐसी स्थिति में, जहाँ दूसरे लोग उसे पुन: उत्पन्न करने के लिए पर्याप्त जानकारी भी न दी गई हो, सार्वजनिक रूप से यह दावा किया जाए कि कोई चीज़ अच्छी नहीं है,
तो भले ही आपका ऐसा इरादा न रहा हो, उस ecosystem में रहने वाले लोगों के लिए यह शायद सुखद बात नहीं लगती।
नमस्ते! सबसे पहले, अपनी बहुमूल्य राय छोड़ने के लिए धन्यवाद। मैं समझ सकता हूँ कि आपने यह बात किस भावना से लिखी है, और अगर आपको ऐसा लगा कि मैंने Go भाषा के भविष्य या उसके users की निंदा की है, तो मैं एक बार फिर स्पष्ट करना चाहूँगा कि ऐसा बिल्कुल नहीं था, और इसके लिए क्षमा चाहता हूँ। और अगर आपको ठीक लगे, तो कृपया लेख के शीर्षक पर क्लिक करके देखें—वहाँ कई data points हैं और किसी अन्य व्यक्ति का blog post भी है, इसलिए (थोड़ा लंबा ज़रूर है) उसे पढ़ेंगे तो मुझे लगता है कि आप मेरी मंशा को और स्पष्ट रूप से समझ पाएँगे।
मुझे लगता है कि भाषाएँ कुछ हद तक कारों जैसी होती हैं। हर कार के अपने फायदे और कमियाँ होती हैं, उन्हें खरीदने की लागत अलग-अलग होती है, और भले ही वे एक जैसा काम करती दिखें, वे अलग-अलग तरह की value को pursue करती हैं—मुझे इनमें यह समानता दिखती है। बेशक, किसी खास वाहन के लिए लगाव और प्रेम होना भी बिल्कुल स्वाभाविक है। मैं भी अपनी कार से प्यार करता हूँ और उसके निर्माता पर भरोसा करता हूँ।
फिर भी, मेरी अपनी कार को लेकर कुछ अफसोस या शिकायतें भी हैं, और जो reviewers नियमित रूप से car models की समीक्षा करते हैं, वे हमेशा competing models के साथ कई पहलुओं में तुलना करके अपनी बातें साझा करते हैं। अगर कोई मेरी कार के बारे में कहे कि उसका transmission performance अच्छा नहीं है, या उसका fuel efficiency खराब है, तो सच कहूँ तो मुझे भी अच्छा नहीं लगता। फिर भी, मैं driver के रूप में खुद को और कार को अलग-अलग सोचने की कोशिश करता हूँ। साथ ही, मैं जिस कार को चलाता हूँ उसके बारे में—चाहे उसकी खूबियाँ हों या कमियाँ—और अधिक जानने की कोशिश करता हूँ। हो सकता है कि मैं भविष्य में कोई दूसरी कार भी चलाऊँ, लेकिन अभी का driving experience तब भी मेरे काम आएगा।
संक्षिप्त version में मैं यह बात ज़्यादा नहीं कह पाया, लेकिन blog के मुख्य भाग में मैंने अंत में यही लिखा था कि Go की कुछ कमियाँ होने के बावजूद उसके फायदे अब भी अधिक हैं, इसलिए मैं इसे आगे भी इस्तेमाल (=ड्राइव) करता रहना चाहता हूँ। मेरा मानना है कि हर भाषा जिन values या strengths का पीछा करती है, वे एक-दूसरे से अलग होती हैं, इसलिए मैं यथासंभव अलग-अलग भाषाएँ (=कारें) इस्तेमाल करने की कोशिश करता हूँ। यही वजह है कि मैं पहले से अच्छी तरह इस्तेमाल कर रहे JS runtime को छोड़कर भी खास तौर पर Go भाषा की ओर जाना चाहता हूँ।
मैंने अपनी तरफ से पूरी सावधानी के साथ यह लेख लिखा था ताकि अनावश्यक language wars न हों। फिर भी, अगर इस लेख को पढ़कर किसी Gopher को बुरा लगा हो, तो मैं फिर से आशा करता हूँ कि वे मन हल्का करें। और इसी के साथ मैं अपनी बात समाप्त करता हूँ यह बताते हुए कि मैं वह romantic coder भी हूँ जो इतनी आलोचना झेल चुकी PHP भाषा से भी प्यार करता है!
मूल लेख में धीमे हिस्सों के बारे में लेखक का अपना विश्लेषण और इसके बावजूद Go का इस्तेमाल करने के कारण लिखे हुए हैं, इसलिए यह समझना थोड़ा मुश्किल है कि आपने किस वजह से इस लेख को मूल्य-निर्णय के रूप में लिया।
यह थोड़ा TMI है, लेकिन समय के साथ Go की std लाइब्रेरी की performance गिर रही है। इसका मुख्य कारण RFC standards का पालन करने के लिए अलग-अलग features जोड़े जाना और उनके साथ report होने वाली कई security vulnerabilities के बीच का trade-off है.
हाल में FIPS certification पास करने के लिए शायद performance का नुकसान थोड़ा और बढ़ने की उम्मीद है।
ऐसी सारी पृष्ठभूमि को पूरी तरह हटाकर, सिर्फ़ सबसे simple किसी खास scenario के बारे में यह एक लाइन लिख देना कि performance अच्छी नहीं है, मुझे लगता है कि इससे बहुत लोगों में गलतफ़हमी पैदा हो सकती है, ऐसा दुख जताने वाला इमोटिकॉन
मैं
tsboardके 1.0 वर्ज़न का इंतज़ार कर रहा हूँ, हा हाइंतज़ार करने के लिए धन्यवाद! मैं खुशी-खुशी इस पर काम करता रहूंगा, हाहा
मेरा मानना है कि JS JIT इस्तेमाल करता है, इसलिए उसके खास तौर पर धीमा होने की कोई वजह नहीं दिखती।
मल्टीथ्रेडिंग, स्थिरता वगैरह को छोड़ दें तो..
इस benchmark के ज़रिए मैंने भी एक नई बात खोजी(?)। stability भी इतनी समस्या वाली नहीं लगी, इसलिए मैं यह बात थोड़ा साहस के साथ कह सकता हूँ। multi-threading में निश्चित रूप से orchestration की ज़रूरत होती है (पता नहीं इसे ऐसे लिखना सही है या नहीं), इसलिए यह थोड़ा झंझटभरा होना सच है.
साइट खुल नहीं रही है, क्या सिर्फ मेरे साथ ऐसा हो रहा है?
नमस्ते! कमेंट में बताने के लिए धन्यवाद, हाहा। अभी तक मैं साइट को होस्टिंग पर माइग्रेट नहीं कर पाया हूँ, इसलिए कभी-कभी एक्सेस में दिक्कत हो जाती है! मैं कोशिश करूँगा कि जितनी जल्दी हो सके इसे ठीक कर दूँ। (अभी घर पर mini PC पूरी मेहनत से काम कर रहा है 😂)
ओह, अब हो रहा है। मैं इसे ध्यान से पढ़ूंगा!
साइट को कमरे के कोने में रखे mini PC से एक छोटे-से virtual server पर माइग्रेट कर दिया गया है...! आज अनपेक्षित रूप से बहुत सारे लोग आए और उन्हें बीच में ही लौटना पड़ा, लेकिन अब मैं आपको बताना चाहता हूँ कि अब कोई समस्या नहीं है!
मुझे जिज्ञासा है कि
github.com/jackc/pgx/v5ड्राइवर और PostgreSQL के साथ प्रयोग करने पर क्या अलग नतीजे आएंगे।मुझे भी जिज्ञासा है कि क्या यह नतीजा केवल mysql तक सीमित है, या DB का उपयोग करने वाले सभी scenarios पर लागू होता है। मुझे लगता है कि कभी न कभी दूसरे लोग भी अपने नतीजे साझा करेंगे haha