क्या Scala 3 ने हमें धीमा कर दिया?

 (kmaliszewski9.github.io)
4 पॉइंट द्वारा GN⁺ 2025-12-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Scala 2.13 से Scala 3 में कोडबेस माइग्रेशन के दौरान अप्रत्याशित performance गिरावट देखी गई
  • शुरुआती टेस्ट और deployment वातावरण में सभी संकेतक सामान्य थे, लेकिन कुछ घंटे बाद Kafka lag बढ़ने लगा
  • load test के परिणामों में, सूक्ष्म स्तर पर विभाजित संदेश प्रोसेसिंग के समय throughput तेजी से गिरा यह स्पष्ट हुआ
  • async-profiler analysis से पता चला कि कारण Quicklens लाइब्रेरी का chain evaluation inefficiency बग था
  • लाइब्रेरी अपडेट के बाद performance वापस सामान्य हो गया, और Scala संस्करणों के बीच लाइब्रेरी व्यवहार के अंतर के प्रति सावधानी की जरूरत पर जोर दिया गया

सेवा माइग्रेशन प्रक्रिया

  • मौजूदा सेवा को Scala 2.13 से Scala 3.7.3 पर माइग्रेट किया गया
    • यह मैक्रो का उपयोग न करने वाली data-collection केंद्रित सेवा थी, और performance यहाँ महत्वपूर्ण घटक था
    • dependencies, compiler options, types और syntax में बदलाव लागू करने के बाद compilation सफल रहा
  • टेस्ट वातावरण और चरणबद्ध deployment में भी logs और metrics दोनों सामान्य दिखे
    • infrastructure, JVM और application स्तर के metrics भी healthy थे

कारण अज्ञात performance गिरावट

  • deployment के लगभग 5–6 घंटे बाद Kafka lag बढ़ने की घटना हुई
    • data spike की स्थिति न होने पर भी प्रति instance throughput में गिरावट देखी गई
    • rollback के बाद throughput तुरंत वापस आ गया, जिससे कोड बदलाव को कारण के रूप में पुष्टि मिली

performance विश्लेषण और कारण ट्रैकिंग

  • load test में शुरुआती चरणों में performance regression reproduce नहीं हुई
    • केवल संदेशों की granular विभाजन और heterogeneous payload वाले मामलों में ही throughput तेजी से गिरा
  • dependency libraries (serialization, DB SDK, Docker image, config libraries आदि) को एक-एक करके revert करके test करने पर भी कोई बदलाव नहीं दिखा
  • async-profiler से CPU profiling के परिणाम में,
    • Scala 3 में JIT compiler और decoding चरण में CPU usage में तेज उछाल दिखा
    • Flamegraph के शीर्ष भाग में Quicklens calls कुल CPU time का लगभग आधा हिस्सा ले रही थीं
    • Scala 2.13 में वही call केवल 0.5% के आसपास थी

समस्या की मूल वजह

  • Quicklens लाइब्रेरी का chain evaluation inefficiency बग Scala 3 में पाया गया
    • संबंधित फिक्स GitHub PR #115 में merge किया गया है
    • लाइब्रेरी अपडेट के बाद Scala 3 और 2.13 के बीच का performance अंतर समाप्त हो गया

सीख और सिफारिशें

  • metaprogramming पर निर्भर libraries Scala संस्करणों के बीच performance gap पैदा कर सकती हैं
  • माइग्रेशन सफल दिखे तब भी hotspots और bottlenecks को benchmark करना चाहिए
  • performance-sensitive सेवाओं में “सब ठीक काम कर रहा है” मानने के बजाय, actual measurement-based validation अनिवार्य है
  • ऐसा न हो कि code अच्छे लगने पर भी benchmark bottleneck दिखा दे; इसलिए पहले से preventive checks जरूरी हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-12-09
Hacker News राय
  • मैं Scala का फैन नहीं हूँ, लेकिन जिस तरह समस्या का गहराई से विश्लेषण और डिबगिंग की गई, वह प्रभावशाली था
    टेक्निकल ब्लॉग ऐसे ही लिखे जाने चाहिए। AI के लिए इस स्तर की सोच-प्रक्रिया की जगह लेना मुश्किल है
    • हमने अपनी एक service को refresh करते समय Scala 2.13 से Scala 3 पर migration किया
      पहला सवाल सीधा था — “क्यों आखिर upgrade करना चाहिए?”
  • Scala 3 में inline keyword macro system के हिस्से के रूप में काम करता है
    parameter पर inline लगाने से compiler को call site पर expression को inline करने का निर्देश मिलता है
    लेकिन अगर वह बड़ा हो, तो JIT compiler पर बहुत बड़ा बोझ पड़ता है
    Scala 2 में @inline सिर्फ एक suggestion था, लेकिन 3 में यह अनिवार्य रूप से लागू होता है
    इसलिए सिर्फ @inline को inline में बदलना बहुत बड़ी गलती है
    • यह अंतर कुछ वैसा ही है जैसा पुराने C/C++ के register keyword के साथ हुआ था
      शुरुआत में वह बाध्यकारी था, लेकिन optimization बेहतर होने के बाद वह सिर्फ एक सिफारिश बन गया और अंततः नज़रअंदाज़ होने लगा
      C++ का inline भी कुछ ऐसा ही रास्ता तय कर चुका है
    • Kotlin लगभग हर जगह inline का आक्रामक इस्तेमाल करता है
      map जैसी functions में lambda overhead हटाने के लिए
      performance की समस्या लगभग नहीं दिखी, लेकिन Scala के macro system के साथ मिलकर जटिल expressions बनें तो समस्या हो सकती है
  • Library upgrade करने के बाद Scala 3 की performance Scala 2.13 के लगभग समान हो गई
    Ruby 2→3 upgrade के समय भी ऐसा ही अनुभव हुआ था
    सिर्फ language version बढ़ाना काफी नहीं होता, पूरी dependency chain को update करना पड़ता है ताकि system stable रहे
  • Scala 3 की समस्या यह है कि इसे कोई चाहता ही नहीं था
    Scala 2 की type inference समस्याएँ अब भी हल नहीं हुईं, लेकिन भाषा ही बदल दी गई
    यानी market की ज़रूरतों को नज़रअंदाज़ करके ऐसा product बना दिया गया जिसे कोई नहीं चाहता था
    PS: compiler के लिए एक असली unit test suite बनाना चाहिए
    • दुख की बात है, लेकिन मैं सहमत हूँ। Scala करीब 2010~15 के बीच काफ़ी promising था
      लेकिन Scala 3 rewrite compile speed और tooling की समस्याएँ हल नहीं कर पाया, और project ने पूरी तरह momentum खो दिया
      अब 2025 में कोई नया project Scala में शुरू करेगा, ऐसा लगता नहीं
    • मैंने कई बार Scala सीखने की कोशिश की, लेकिन आखिरकार Clojure पर लौट गया
      Scala मुझे अकादमिक लोगों द्वारा बनाई गई भाषा जैसी लगी, और industry में इसका कुछ समय तक लोकप्रिय होना ही उल्टा अजीब लगा
    • बात बिल्कुल सही पकड़ी गई
      अब हर tool को Scala 3 के मुताबिक ढलना पड़ रहा है, और यहाँ तक कि IntelliJ भी अभी तक इसे पूरी तरह support नहीं कर पाता
      अच्छा होता अगर Scala 2 को धीरे-धीरे बेहतर बनाया जाता, लेकिन लगता है ध्यान सिर्फ शैक्षणिक सफलता पर था
      उदाहरण के लिए tpolecat का लेख देखें, जहाँ early return पर भी बहुत बहस होती है, जबकि Kotlin इसे बिना किसी समस्या के support करता है
    • “tests नहीं हैं” कहना गलत जानकारी है
      Scala compiler में हजारों-लाखों tests हैं,
      official test directory और
      community build system के ज़रिए लाखों LOC validate किए जाते हैं
    • लगता है लेख ठीक से पढ़ा नहीं गया। मुद्दा पूरी तरह चूक गया
  • इस लेख की सबसे दिलचस्प बात यह थी कि automated performance tests और flamegraph analysis बुनियादी रूप से तैयार होने चाहिए
    खासकर language version upgrade जैसे बड़े बदलावों में यह अनिवार्य है
    • Benchmark tests को सामान्य tests की तुलना में कहीं ज़्यादा बारीक setup चाहिए
      हम C++ में लिखे tool का लगातार benchmark करते हैं, लेकिन environment noise की वजह से consistent results पाना मुश्किल होता है
      हम इस पर विचार कर रहे हैं कि एक ही machine पर कई बार run करके तुलना की जाए
    • जानना चाहूँगा कि JVM पर आजकल कौन से performance testing tools इस्तेमाल किए जाते हैं
  • Scala 3 की असली समस्या सिर्फ Python से ईर्ष्या है
    दूसरी syntax बनाकर उसे future बताकर आगे बढ़ाना ही गड़बड़ थी
    इससे tooling ecosystem भी धीमा पड़ गया
    • अब ज़्यादातर tools नई syntax को support करते हैं
      compiler या scalafmt से style को अपने-आप convert भी किया जा सकता है
    • Scala की तरह अब एक ही काम कई तरीकों से किया जा सकता है
      अब braces syntax और indentation syntax, दोनों मिलाकर विकल्प दोगुने हो गए हैं
    • इसकी तुलना अगर Haskell से की जाती तो शायद ज़्यादा आकर्षक लगती
    • Scala का पुराना फैन होने के नाते, नई syntax के उदाहरण देखकर मैं हैरान रह गया
      match syntax बहुत verbose लगती है और Python की नकल जैसी दिखती है
  • मैंने पहले Scala 2.x migration किया था, और dependencies का इंतज़ार सबसे मुश्किल हिस्सा था
    उस समय Spark की वजह से Scala पर ध्यान गया था, लेकिन यह commercial language के रूप में आगे बढ़ने का मौका खो बैठा
    अब Spark Python की तरफ है, और JVM की आधुनिक language वाली जगह Kotlin ने ले ली है
    आखिरकार Scala फिर से एक अकादमिक भाषा जैसा महसूस होता है
    • लेकिन Scala अब भी बड़े enterprises में काफ़ी इस्तेमाल होती है
      यह Scala Adoption Tracker से देखा जा सकता है
      Scala 3 की नई सुविधाओं में language ecosystem को फिर से innovate करने की क्षमता है
      उदाहरण: Capture Checking की व्याख्या
    • Kotlin ने सच में JVM पर कब्ज़ा कर लिया है, इस पर संदेह है
      Java ने functional features जोड़कर Scala की कुछ appeal अपने अंदर समेट ली है
    • Server-side JVM पर Kotlin की मौजूदगी लगभग नहीं के बराबर है
      मेरे अनुभव में market demand भी बहुत कम है
    • Kotlin असल में लगभग Android-केवल भाषा है
      Google ने Java support सीमित किया, इसलिए ऐसा हुआ
      पूरे JVM बाज़ार में इसकी हिस्सेदारी सिर्फ करीब 10% है
  • यह अजीब लगा कि library versions upgrade किए बिना Scala 3 पर चला गया
    अगर security audit (PIC-DSS आदि) से गुजरना हो, तो libraries को up-to-date रखना ज़रूरी है
    • “up-to-date रहना अच्छी आदत है” कहना चर्चा रोक देने वाला वाक्य है
      मैं तो उल्टा dependencies को पुराना ही बनाए रखने की तरफ झुकता हूँ
      नए versions नए bugs लाते हैं, और maintainer बदलने या security risk भी हो सकते हैं
    • मैं भी उलझ गया था। लेख में पहले कहा गया कि “dependencies update कीं”, लेकिन बाद में कहा कि “update के बाद performance बराबर हो गई”
      लगता है शुरू में सिर्फ कुछ हिस्से ही upgrade किए गए थे। छोटे चरणों में बाँटना आम बात है, लेकिन शायद किस्मत खराब रही
    • Bug का कारण समझ में आने के बाद यह कम प्रभावशाली लगा
      समस्या Scala 3 खुद नहीं थी, बल्कि कई कारकों की परस्पर क्रिया थी
    • Language version upgrade जैसे बड़े बदलावों में एक बार में एक ही चीज़ बदलना बेहतर होता है
    • Maven/Gradle/SBT में version constraints लगाकर इन्हें language version से अलग रखा जा सकता है
      लेकिन Scala-specific libraries में version में Scala version भी शामिल होता है, इसलिए सावधानी चाहिए
  • SoftwareMill और Scala GitHub की bug reports छोटी लेकिन सटीक fixes थीं
    Scala की expressiveness और type safety साफ़ नज़र आई
    Li Haoyi का लेख की तरह यह Python के विकल्प के रूप में भी काफ़ी आकर्षक लगती है
  • मुख्य सीख यह है कि language या framework के major upgrade के समय libraries को भी साथ में update करना चाहिए
    खासकर तब, जब बहुत सी libraries magic features का ज़्यादा इस्तेमाल करती हों