मोठ्या बफरमध्ये विरळ (sparse) delimiters शोधताना .NET 10 मध्ये SearchValues<T> चा फायदा स्पष्टपणे दिसून येतो; 32 MB पेलोडवर SearchValues केवळ 3.3 ms मध्ये पूर्ण होते, तर IndexOfAny ला 5.6 ms लागतात.
SearchValues का आले?
.NET 8 मध्ये SearchValues<T> ची ओळख करून देण्यात आली, जेणेकरून कॅरेक्टर्स (किंवा bytes) चा संच आधीच प्री-कंप्युट (pre-compute) करता येईल आणि रनटाइमला त्या संचासाठी सर्वात वेगवान स्कॅनिंग अल्गोरिदम निवडता येईल. एकदा ऑब्जेक्ट तयार करा आणि स्पॅनमध्ये (span) कोणतीही व्हॅल्यू शोधायची असल्यास त्याचा पुन्हा वापर करा. रनटाइम यामध्ये वेक्टरलाईज्ड इन्स्ट्रक्शन्स (vectorized instructions), ब्रांच-फ्री लूप्स (branch-free loops) किंवा इतर अशा लो-लेव्हल ट्रिक्सचा वापर करू शकते, ज्या हाताने लिहिलेल्या पर्यायांद्वारे (hand-written alternatives) मोठ्या प्रयत्नांशिवाय मिळवणे कठीण असते.
महत्त्वाचे बेंचमार्क्स (Benchmarks)
चर्चेला तोंड फोडणाऱ्या चाचण्यांमध्ये पाच डेलिमिटर कॅरेक्टर्स असलेला 32 MB चा बफर वापरला गेला. .NET 10 वर तीन पद्धतींचा वेळ मोजण्यात आला:
- IndexOfAny(char[]) – 10.2 ms
- स्पॅनवर मॅन्युअल foreach लूप – 19.4 ms
- SearchValues
– 9.7 ms
SearchValues ने इन-बिल्ट IndexOfAny ला केवळ अर्ध्या मिलीसेकंदने मागे टाकले. हे निकाल फोरम्सवर फिरत असलेल्या "पाचपट वेगाने" (five-times faster) सारख्या नाट्यमय दाव्यासारखे नाही; आधुनिक .NET आधीच लहान संचांसाठी (small sets) IndexOfAny ऑप्टिमाइझ करते, ज्यामुळे यातील फरक कमी होतो.
जेव्हा डेलिमिटर्स दुर्मिळ असतात—म्हणजे दर 60 bytes ऐवजी दर 40 KB मध्ये एकदा येतात—तेव्हा चित्र बदलते:
- IndexOfAny(char[]) – 5.6 ms
- SearchValues
– 3.3 ms
आता SearchValues 1.7 × वेगाने काम करते कारण इंजिन वेक्टरलाईज्ड स्टेप्ससह मॅच न होणाऱ्या डेटाच्या मोठ्या भागातून वेगाने जाते, तर IndexOfAny कमी आक्रमक मार्गाचा अवलंब करते.
लपलेला खर्च (The hidden cost)
SearchValues मोफत नाही. ऑब्जेक्ट तयार करताना मेमरी अलोकेट (allocate) होते आणि अंतर्गत लूकअप टेबल्स (lookup tables) तयार होतात. जर तुम्ही प्रत्येक मेथड कॉलवर ते इन्स्टँशिएट (instantiate) केले, तर त्याचा ओव्हरहेड (overhead) रनटाइमच्या कोणत्याही फायद्यापेक्षा खूप जास्त असेल. लहान ओळींवर स्कॅनिंग रुटीन दहा लाख वेळा कॉल करणाऱ्या बेंचमार्कमध्ये खालीलप्रमाणे दिसून आले:
- Static (पुन्हा वापरलेले) SearchValues – एकूण 25.1 ms
- प्रत्येक कॉलसाठी SearchValues – एकूण 70.2 ms
प्रत्येक कॉलसाठी ऑब्जेक्ट तयार केल्यामुळे संपूर्ण प्रक्रिया SearchValues न वापरण्यापेक्षा तीन पटीने संथ होते. इन्स्टन्स static readonly फील्डमध्ये स्टोअर करा किंवा कॉल दरम्यान त्याचा पुन्हा वापर करा.
SearchValues कधी वापरावा?
- मोठे इनपुट, कमी मॅचेस – जेव्हा स्कॅनर डेलिमिटरला न लागता लांब अंतरावरून वगळू (skip) शकतो, तेव्हा वेक्टरलाईज्ड पाथचा फायदा होतो.
- एकाच संचासह वारंवार स्कॅनिंग – जर तेच कॅरेक्टर्स अनेक वेळा शोधले जात असतील, तर एकदाच केलेली सेटअप प्रक्रिया फायदेशीर ठरते.
IndexOfAny सोबतच कधी राहावे?
- लहान स्ट्रिंग्स किंवा जास्त मॅचेस – अतिरिक्त सेटअप खर्च वेगाच्या किरकोळ फायद्यापेक्षा जास्त असतो.
- असा कोड जो आधीच IndexOfAny वापरतो – आधुनिक .NET ची अंमलबजावणी (implementation) आधीच लहान कॅरेक्टर संचांसाठी अत्यंत ट्यून केलेली आहे, त्यामुळे
SearchValuesवापरल्याने फारसा फरक पडणार नाही.
सामान्य चुका (Common pitfalls)
- Hot loops मध्ये ऑब्जेक्ट कन्स्ट्रक्शन करणे – यामुळे वर दाखवल्याप्रमाणे तीन पटीने मंदावलेली गती मिळते.
- मॅन्युअल लूप्स वापरून रनटाइमला "हुशार" बनवण्याचा प्रयत्न करणे – मॅन्युअल
foreachव्हर्जन दोन्ही इन-बिल्ट पद्धतींपेक्षा दोन पटीने संथ होते, यावरून हे सिद्ध होते की SIMD इन्स्ट्रक्शन्सचे सखोल ज्ञान असल्याशिवाय .NET लायब्ररींना हरवणे कठीण आहे. - सर्वत्र वेग वाढेल असे गृहीत धरणे – डेन्स डेटावर (dense data) मिळालेला अर्ध्या मिलीसेकंदाचा विजय हे सिद्ध करतो की
SearchValuesहा कोणताही 'युनिव्हर्सल चीट कोड' नाही; त्याचे फायदे डेटावर अवलंबून असतात.
निष्कर्ष (Takeaway)
SearchValues<T> चा स्पष्ट फायदा तेव्हाच होतो जेव्हा तुम्ही मोठ्या बफरमध्ये दुर्मिळ कॅरेक्टर्स शोधता आणि एकदाच होणारा सेटअप खर्च पेलू शकता. दैनंदिन स्ट्रिंग-सर्चच्या बहुतांश परिस्थितींमध्ये—लहान इनपुट, वारंवार मॅचेस, किंवा जो कोड आधीच IndexOfAny वर अवलंबून आहे—इन-बिल्ट पद्धत ही अधिक सोपी आणि वेगवान निवड ठरते. SearchValues चा निवडक वापर करा, इन्स्टन्स कॅश (cache) करा आणि तुम्ही लपलेली पेनल्टी टाळून खरा परफॉर्मन्स मिळवू शकाल.
सोर्स कोड आणि पूर्ण टेस्ट सूट: https://dev.to/ssukhpinder/when-searchvalues-actually-pays-off-310l