પ્રતિબિંબને વેગ આપવા વિશેનો અસફળ લેખ

હું તરત જ લેખનું શીર્ષક સમજાવીશ. મૂળ યોજના એક સરળ પરંતુ વાસ્તવિક ઉદાહરણનો ઉપયોગ કરીને પ્રતિબિંબના ઉપયોગને કેવી રીતે ઝડપી બનાવવી તે અંગે સારી, વિશ્વસનીય સલાહ આપવાનો હતો, પરંતુ બેન્ચમાર્કિંગ દરમિયાન તે બહાર આવ્યું કે પ્રતિબિંબ એટલું ધીમું નથી જેટલું મેં વિચાર્યું હતું, LINQ મારા સ્વપ્નો કરતાં ધીમું છે. પણ અંતે એવું બહાર આવ્યું કે મેં માપમાં પણ ભૂલ કરી હતી... આ જીવનકથાની વિગતો કટ અને કોમેન્ટમાં છે. ઉદાહરણ તદ્દન સામાન્ય હોવાથી અને સામાન્ય રીતે એન્ટરપ્રાઇઝમાં કરવામાં આવે છે તેમ સૈદ્ધાંતિક રીતે અમલમાં મૂકવામાં આવે છે, તે ખૂબ જ રસપ્રદ બન્યું, કારણ કે તે મને લાગે છે, જીવનનું પ્રદર્શન: લેખના મુખ્ય વિષયની ગતિ પર અસર હતી. બાહ્ય તર્કને કારણે ધ્યાનપાત્ર નથી: Moq, Autofac, EF કોર અને અન્ય "બેન્ડિંગ્સ".

મેં આ લેખની છાપ હેઠળ કામ કરવાનું શરૂ કર્યું: પ્રતિબિંબ કેમ ધીમું છે

જેમ તમે જોઈ શકો છો, લેખક પ્રતિબિંબ પ્રકારની પદ્ધતિઓને સીધા કૉલ કરવાને બદલે સંકલિત પ્રતિનિધિઓનો ઉપયોગ કરવાનું સૂચન કરે છે જે એપ્લિકેશનને મોટા પ્રમાણમાં ઝડપી બનાવવા માટે એક સરસ રીત છે. અલબત્ત, IL ઉત્સર્જન છે, પરંતુ હું તેને ટાળવા માંગુ છું, કારણ કે આ કાર્ય કરવા માટેની સૌથી શ્રમ-સઘન રીત છે, જે ભૂલોથી ભરપૂર છે.

પ્રતિબિંબની ગતિ વિશે મેં હંમેશા સમાન અભિપ્રાય રાખ્યો છે તે ધ્યાનમાં લેતા, મારો ખાસ કરીને લેખકના નિષ્કર્ષ પર પ્રશ્ન કરવાનો ઇરાદો નહોતો.

હું ઘણીવાર એન્ટરપ્રાઇઝમાં પ્રતિબિંબનો નિષ્કપટ ઉપયોગ અનુભવું છું. પ્રકાર લેવામાં આવે છે. મિલકત વિશે માહિતી લેવામાં આવે છે. સેટવેલ્યુ પદ્ધતિ કહેવામાં આવે છે અને દરેકને આનંદ થાય છે. લક્ષ્ય ક્ષેત્રમાં મૂલ્ય આવ્યું છે, દરેક ખુશ છે. ખૂબ જ સ્માર્ટ લોકો - વરિષ્ઠ અને ટીમ લીડ્સ - તેમના એક્સ્ટેંશનને ઑબ્જેક્ટ પર લખે છે, આવા નિષ્કપટ અમલીકરણને આધારે "સાર્વત્રિક" મેપર્સ એક પ્રકારથી બીજા. સાર સામાન્ય રીતે આ છે: આપણે બધા ક્ષેત્રો લઈએ છીએ, બધી મિલકતો લઈએ છીએ, તેના પર પુનરાવર્તન કરીએ છીએ: જો પ્રકારના સભ્યોના નામ મેળ ખાય છે, તો અમે સેટવેલ્યુ ચલાવીએ છીએ. સમય સમય પર અમે ભૂલોને કારણે અપવાદો પકડીએ છીએ જ્યાં અમને એક પ્રકારમાં કેટલીક મિલકત મળી નથી, પરંતુ અહીં પણ એક રસ્તો છે જે કાર્યક્ષમતામાં સુધારો કરે છે. પ્રયાસ કરો/પકડો.

મેં લોકોને પાર્સર્સ અને મેપર્સને તેમની પહેલાં આવેલા મશીનો કેવી રીતે કાર્ય કરે છે તે વિશેની માહિતી સાથે સંપૂર્ણ રીતે સજ્જ થયા વિના ફરીથી શોધતા જોયા છે. મેં જોયું છે કે લોકો તેમના નિષ્કપટ અમલીકરણને વ્યૂહરચનાઓ પાછળ, ઇન્ટરફેસ પાછળ, ઇન્જેક્શન પાછળ છુપાવતા હોય છે, જાણે કે આ અનુગામી બૅકનાલિયાને માફ કરશે. આવી અનુભૂતિ પર મેં નાક ઉપર વાળ્યું. વાસ્તવમાં, મેં વાસ્તવિક પ્રદર્શન લીકને માપ્યું ન હતું, અને, જો શક્ય હોય તો, જો હું તેના પર હાથ મેળવી શકું તો મેં અમલીકરણને વધુ "શ્રેષ્ઠ" માં બદલી નાખ્યું. તેથી, નીચે ચર્ચા કરેલ પ્રથમ માપ મને ગંભીરતાથી મૂંઝવણમાં મૂકે છે.

મને લાગે છે કે તમારામાંના ઘણા, રિક્ટર અથવા અન્ય વિચારધારકોને વાંચતા, સંપૂર્ણ ન્યાયી નિવેદનમાં આવ્યા છે કે કોડમાં પ્રતિબિંબ એ એક એવી ઘટના છે જે એપ્લિકેશનની કામગીરી પર અત્યંત નકારાત્મક અસર કરે છે.

પ્રતિબિંબને કૉલ કરવાથી CLR ને તેઓની જરૂર હોય તે શોધવા, તેમના મેટાડેટાને ખેંચવા, તેનું વિશ્લેષણ કરવા વગેરે માટે એસેમ્બલીમાંથી પસાર થવાની ફરજ પડે છે. વધુમાં, ક્રમને પાર કરતી વખતે પ્રતિબિંબ મોટી માત્રામાં મેમરીની ફાળવણી તરફ દોરી જાય છે. અમે મેમરીનો ઉપયોગ કરી રહ્યા છીએ, CLR GC ને ખોલે છે અને ફ્રીઝ શરૂ થાય છે. તે નોંધપાત્ર રીતે ધીમું હોવું જોઈએ, મારા પર વિશ્વાસ કરો. આધુનિક પ્રોડક્શન સર્વર્સ અથવા ક્લાઉડ મશીનો પર મેમરીની વિશાળ માત્રા ઉચ્ચ પ્રોસેસિંગ વિલંબને અટકાવતી નથી. વાસ્તવમાં, જેટલી વધુ મેમરી, તમે GC કેવી રીતે કામ કરે છે તે ધ્યાનમાં લેવાની શક્યતા વધુ હશે. પ્રતિબિંબ, સિદ્ધાંતમાં, તેના માટે એક વધારાનો લાલ રાગ છે.

જો કે, અમે બધા IoC કન્ટેનર અને તારીખ મેપર્સનો ઉપયોગ કરીએ છીએ, જેનો ઓપરેટિંગ સિદ્ધાંત પણ પ્રતિબિંબ પર આધારિત છે, પરંતુ સામાન્ય રીતે તેમના પ્રદર્શન વિશે કોઈ પ્રશ્નો નથી. ના, એટલા માટે નહીં કે બાહ્ય મર્યાદિત સંદર્ભ મોડેલોમાંથી નિર્ભરતા અને અમૂર્તતાનો પરિચય એટલો જરૂરી છે કે આપણે કોઈ પણ સંજોગોમાં પ્રદર્શનને બલિદાન આપવું પડશે. બધું સરળ છે - તે ખરેખર પ્રભાવને વધુ અસર કરતું નથી.

હકીકત એ છે કે પ્રતિબિંબ તકનીક પર આધારિત સૌથી સામાન્ય ફ્રેમવર્ક તેની સાથે વધુ શ્રેષ્ઠ રીતે કામ કરવા માટે તમામ પ્રકારની યુક્તિઓનો ઉપયોગ કરે છે. સામાન્ય રીતે આ એક કેશ છે. સામાન્ય રીતે આ એક્સપ્રેશન ટ્રીમાંથી સંકલિત અભિવ્યક્તિઓ અને પ્રતિનિધિઓ છે. આ જ ઓટોમેપર સ્પર્ધાત્મક શબ્દકોશ જાળવી રાખે છે જે પ્રકારો સાથે મેળ ખાય છે જે પ્રતિબિંબને કૉલ કર્યા વિના એક બીજામાં રૂપાંતરિત કરી શકે છે.

આ કેવી રીતે પ્રાપ્ત થાય છે? અનિવાર્યપણે, આ તે તર્કથી અલગ નથી કે જે પ્લેટફોર્મ પોતે JIT કોડ જનરેટ કરવા માટે વાપરે છે. જ્યારે કોઈ પદ્ધતિને પ્રથમ વખત બોલાવવામાં આવે છે, ત્યારે તે સંકલિત કરવામાં આવે છે (અને, હા, આ પ્રક્રિયા ઝડપી નથી); અનુગામી કૉલ્સ પર, નિયંત્રણ પહેલાથી સંકલિત પદ્ધતિમાં સ્થાનાંતરિત થાય છે, અને તેમાં કોઈ નોંધપાત્ર કામગીરીમાં ઘટાડો થશે નહીં.

અમારા કિસ્સામાં, તમે JIT સંકલનનો પણ ઉપયોગ કરી શકો છો અને પછી તેના AOT સમકક્ષો જેવા જ પ્રદર્શન સાથે સંકલિત વર્તનનો ઉપયોગ કરી શકો છો. આ કિસ્સામાં અભિવ્યક્તિઓ અમારી મદદ માટે આવશે.

પ્રશ્નમાંના સિદ્ધાંતને સંક્ષિપ્તમાં નીચે પ્રમાણે ઘડી શકાય છે:
તમારે પ્રતિબિંબના અંતિમ પરિણામને સંકલિત કાર્ય ધરાવતા પ્રતિનિધિ તરીકે કેશ કરવું જોઈએ. તમારા પ્રકાર, કાર્યકર, જે ઑબ્જેક્ટની બહાર સંગ્રહિત છે તેના ક્ષેત્રોમાં પ્રકારની માહિતી સાથે તમામ જરૂરી ઑબ્જેક્ટ્સને કૅશ કરવામાં પણ અર્થપૂર્ણ છે.

આમાં તર્ક છે. સામાન્ય જ્ઞાન આપણને કહે છે કે જો કંઈક સંકલિત અને કેશ કરી શકાય છે, તો તે કરવું જોઈએ.

આગળ જોતાં, એવું કહેવું જોઈએ કે પ્રતિબિંબ સાથે કામ કરતી કેશમાં તેના ફાયદા છે, ભલે તમે અભિવ્યક્તિઓનું સંકલન કરવાની સૂચિત પદ્ધતિનો ઉપયોગ ન કરો. વાસ્તવમાં, અહીં હું ફક્ત લેખના લેખકની થીસીસનું પુનરાવર્તન કરું છું જેનો મેં ઉપર ઉલ્લેખ કર્યો છે.

હવે કોડ વિશે. ચાલો એક ઉદાહરણ જોઈએ જે મારી તાજેતરની પીડા પર આધારિત છે જેનો મને ગંભીર ક્રેડિટ સંસ્થાના ગંભીર ઉત્પાદનમાં સામનો કરવો પડ્યો હતો. બધી સંસ્થાઓ કાલ્પનિક છે જેથી કોઈ અનુમાન ન કરે.

અમુક સાર છે. સંપર્ક થવા દો. પ્રમાણભૂત શરીર સાથેના અક્ષરો છે, જેમાંથી પાર્સર અને હાઇડ્રેટર આ સમાન સંપર્કો બનાવે છે. એક પત્ર આવ્યો, અમે તેને વાંચ્યો, તેને કી-વેલ્યુ જોડીમાં વિશ્લેષિત કર્યો, એક સંપર્ક બનાવ્યો અને તેને ડેટાબેઝમાં સાચવ્યો.

તે પ્રાથમિક છે. ચાલો કહીએ કે સંપર્કમાં સંપૂર્ણ નામ, ઉંમર અને સંપર્ક ફોન ગુણધર્મો છે. આ ડેટા પત્રમાં પ્રસારિત થાય છે. પત્રના મુખ્ય ભાગમાં જોડીમાં એન્ટિટી પ્રોપર્ટીઝના મેપિંગ માટે નવી કીઝને ઝડપથી ઉમેરવા માટે સમર્થ થવા માટે વ્યવસાય પણ સમર્થન માંગે છે. જો કોઈએ ટેમ્પલેટમાં ટાઈપો કરી હોય અથવા તો રીલીઝ પહેલા નવા ફોર્મેટમાં અનુકૂલન કરીને, નવા ભાગીદાર પાસેથી મેપિંગને તાત્કાલિક લોંચ કરવું જરૂરી છે. પછી અમે સસ્તા ડેટાફિક્સ તરીકે એક નવો મેપિંગ સહસંબંધ ઉમેરી શકીએ છીએ. એટલે કે જીવનનું ઉદાહરણ.

અમે અમલ કરીએ છીએ, પરીક્ષણો બનાવીએ છીએ. કામ કરે છે.

હું કોડ પ્રદાન કરીશ નહીં: ત્યાં ઘણા બધા સ્રોતો છે, અને તે લેખના અંતે લિંક દ્વારા GitHub પર ઉપલબ્ધ છે. તમે તેમને લોડ કરી શકો છો, તેમને માન્યતાની બહાર ત્રાસ આપી શકો છો અને તેમને માપી શકો છો, કારણ કે તે તમારા કેસમાં અસર કરશે. હું ફક્ત બે નમૂના પદ્ધતિઓનો કોડ આપીશ જે હાઇડ્રેટરને અલગ પાડે છે, જે ઝડપી હોવાનું માનવામાં આવતું હતું, હાઇડ્રેટરથી, જે ધીમી હોવાનું માનવામાં આવતું હતું.

તર્ક નીચે મુજબ છે: ટેમ્પલેટ પદ્ધતિ મૂળભૂત પાર્સર તર્ક દ્વારા જનરેટ કરાયેલ જોડીઓ મેળવે છે. LINQ સ્તર એ પાર્સર અને હાઇડ્રેટરનું મૂળભૂત તર્ક છે, જે ડેટાબેઝ સંદર્ભને વિનંતી કરે છે અને પાર્સરની જોડી સાથે કીની તુલના કરે છે (આ કાર્યો માટે સરખામણી માટે LINQ વગરનો કોડ છે). આગળ, જોડીને મુખ્ય હાઇડ્રેશન પદ્ધતિમાં પસાર કરવામાં આવે છે અને જોડીના મૂલ્યો એન્ટિટીના અનુરૂપ ગુણધર્મો પર સેટ કરવામાં આવે છે.

"ઝડપી" (બેન્ચમાર્કમાં ઉપસર્ગ ઝડપી):

 protected override Contact GetContact(PropertyToValueCorrelation[] correlations)
        {
            var contact = new Contact();
            foreach (var setterMapItem in _proprtySettersMap)
            {
                var correlation = correlations.FirstOrDefault(x => x.PropertyName == setterMapItem.Key);
                setterMapItem.Value(contact, correlation?.Value);
            }
            return contact;
        }

જેમ આપણે જોઈ શકીએ છીએ, સેટર પ્રોપર્ટીઝ સાથે સ્થિર સંગ્રહનો ઉપયોગ થાય છે - સંકલિત લેમ્બડાસ કે જે સેટર એન્ટિટી કહે છે. નીચેના કોડ દ્વારા બનાવેલ:

        static FastContactHydrator()
        {
            var type = typeof(Contact);
            foreach (var property in type.GetProperties())
            {
                _proprtySettersMap[property.Name] = GetSetterAction(property);
            }
        }

        private static Action<Contact, string> GetSetterAction(PropertyInfo property)
        {
            var setterInfo = property.GetSetMethod();
            var paramValueOriginal = Expression.Parameter(property.PropertyType, "value");
            var paramEntity = Expression.Parameter(typeof(Contact), "entity");
            var setterExp = Expression.Call(paramEntity, setterInfo, paramValueOriginal).Reduce();
            
            var lambda = (Expression<Action<Contact, string>>)Expression.Lambda(setterExp, paramEntity, paramValueOriginal);

            return lambda.Compile();
        }

સામાન્ય રીતે તે સ્પષ્ટ છે. અમે ગુણધર્મોને પાર કરીએ છીએ, તેમના માટે પ્રતિનિધિઓ બનાવીએ છીએ જે સેટરને બોલાવે છે અને તેમને સાચવીએ છીએ. પછી જરૂર પડે ત્યારે ફોન કરીએ છીએ.

"ધીમો" (બેન્ચમાર્કમાં ધીમો ઉપસર્ગ):

        protected override Contact GetContact(PropertyToValueCorrelation[] correlations)
        {
            var contact = new Contact();
            foreach (var property in _properties)
            {
                var correlation = correlations.FirstOrDefault(x => x.PropertyName == property.Name);
                if (correlation?.Value == null)
                    continue;

                property.SetValue(contact, correlation.Value);
            }
            return contact;
        }

અહીં અમે તરત જ પ્રોપર્ટીઝને બાયપાસ કરીએ છીએ અને સેટવેલ્યુને સીધો કૉલ કરીએ છીએ.

સ્પષ્ટતા માટે અને સંદર્ભ તરીકે, મેં એક નિષ્કપટ પદ્ધતિનો અમલ કર્યો છે જે તેમના સહસંબંધ જોડીના મૂલ્યો સીધા એન્ટિટી ફીલ્ડમાં લખે છે. ઉપસર્ગ - મેન્યુઅલ.

હવે ચાલો BenchmarkDotNet લઈએ અને પ્રદર્શનની તપાસ કરીએ. અને અચાનક... (બગાડનાર - આ સાચું પરિણામ નથી, વિગતો નીચે છે)

આપણે અહીં શું જોઈએ છીએ? ઝડપી ઉપસર્ગને વિજયી રીતે સહન કરતી પદ્ધતિઓ ધીમા ઉપસર્ગ સાથેની પદ્ધતિઓ કરતાં લગભગ તમામ પાસમાં ધીમી હોય છે. આ ફાળવણી અને કામની ઝડપ બંને માટે સાચું છે. બીજી બાજુ, જ્યાં શક્ય હોય ત્યાં આ માટે બનાવાયેલ LINQ પદ્ધતિઓનો ઉપયોગ કરીને મેપિંગનું સુંદર અને ભવ્ય અમલીકરણ, તેનાથી વિપરીત, ઉત્પાદકતામાં ઘણો ઘટાડો કરે છે. તફાવત ઓર્ડરનો છે. પાસની વિવિધ સંખ્યાઓ સાથે વલણ બદલાતું નથી. તફાવત માત્ર સ્કેલમાં છે. LINQ સાથે તે 4 - 200 ગણું ધીમું છે, લગભગ સમાન સ્કેલ પર વધુ કચરો છે.

સુધારાશે

મને મારી આંખો પર વિશ્વાસ ન હતો, પરંતુ વધુ મહત્ત્વની વાત એ છે કે અમારા સાથીદારે મારી આંખો અથવા મારા કોડ પર વિશ્વાસ કર્યો ન હતો - દિમિત્રી ટીખોનોવ 0x1000000. મારા સોલ્યુશનને બે વાર તપાસ્યા પછી, તેણે તેજસ્વી રીતે શોધી કાઢ્યું અને એક ભૂલ દર્શાવી જે અમલીકરણમાં ઘણા ફેરફારોને કારણે ચૂકી ગઈ, પ્રારંભિકથી અંતિમ. Moq સેટઅપમાં મળેલ બગને ઠીક કર્યા પછી, બધા પરિણામો સ્થાને આવી ગયા. પુનઃપરીક્ષણ પરિણામો અનુસાર, મુખ્ય વલણ બદલાતું નથી - LINQ હજુ પણ પ્રતિબિંબ કરતાં પ્રભાવને વધુ અસર કરે છે. જો કે, તે સરસ છે કે અભિવ્યક્તિ સંકલન સાથેનું કાર્ય નિરર્થક થયું નથી, અને પરિણામ ફાળવણી અને અમલના સમય બંનેમાં દેખાય છે. પ્રથમ પ્રક્ષેપણ, જ્યારે સ્થિર ક્ષેત્રો શરૂ થાય છે, ત્યારે "ઝડપી" પદ્ધતિ માટે કુદરતી રીતે ધીમી હોય છે, પરંતુ પછી પરિસ્થિતિ બદલાય છે.

અહીં રીટેસ્ટનું પરિણામ છે:

નિષ્કર્ષ: એન્ટરપ્રાઇઝમાં પ્રતિબિંબનો ઉપયોગ કરતી વખતે, યુક્તિઓનો આશરો લેવાની કોઈ ખાસ જરૂર નથી - LINQ ઉત્પાદકતા વધુ ખાઈ જશે. જો કે, ઉચ્ચ-લોડ પદ્ધતિઓમાં કે જેને ઑપ્ટિમાઇઝેશનની જરૂર હોય છે, તમે ઇનિશિયલાઇઝર્સ અને ડેલિગેટ કમ્પાઇલર્સના રૂપમાં પ્રતિબિંબ સાચવી શકો છો, જે પછી "ઝડપી" તર્ક પ્રદાન કરશે. આ રીતે તમે પ્રતિબિંબની લવચીકતા અને એપ્લિકેશનની ઝડપ બંને જાળવી શકો છો.

બેન્ચમાર્ક કોડ અહીં ઉપલબ્ધ છે. કોઈપણ મારા શબ્દોને બે વાર તપાસી શકે છે:
હેબ્રા રિફ્લેક્શન ટેસ્ટ

PS: પરીક્ષણોમાંનો કોડ IoC નો ઉપયોગ કરે છે, અને બેન્ચમાર્ક્સમાં તે સ્પષ્ટ રચનાનો ઉપયોગ કરે છે. હકીકત એ છે કે અંતિમ અમલીકરણમાં મેં તમામ પરિબળોને કાપી નાખ્યા જે પ્રભાવને અસર કરી શકે અને પરિણામને ઘોંઘાટીયા બનાવી શકે.

PPS: વપરાશકર્તા માટે આભાર દિમિત્રી ટીખોનોવ @0x1000000 Moq સેટ કરવામાં મારી ભૂલ શોધવા માટે, જેણે પ્રથમ માપને અસર કરી. વાચકોમાંથી કોઈ પાસે પૂરતું કર્મ હોય તો લાઈક કરો. માણસ અટક્યો, માણસે વાંચ્યું, માણસે બે વાર તપાસ કરી અને ભૂલ બતાવી. મને લાગે છે કે આ આદર અને સહાનુભૂતિને પાત્ર છે.

PPPS: ઝીણવટભર્યા વાચકનો આભાર કે જેઓ શૈલી અને ડિઝાઇનના તળિયે પહોંચ્યા. હું એકરૂપતા અને સગવડ માટે છું. પ્રસ્તુતિની મુત્સદ્દીગીરી ઇચ્છિત કરવા માટે ઘણું બધું છોડી દે છે, પરંતુ મેં ટીકાને ધ્યાનમાં લીધી. હું અસ્ત્ર માટે પૂછું છું.

સોર્સ: www.habr.com