প্রতিফলনকে ত্বরান্বিত করার বিষয়ে অসফল নিবন্ধ

আমি অবিলম্বে নিবন্ধের শিরোনাম ব্যাখ্যা করব। মূল পরিকল্পনাটি ছিল একটি সহজ কিন্তু বাস্তবসম্মত উদাহরণ ব্যবহার করে প্রতিফলনের ব্যবহার দ্রুত করার বিষয়ে ভাল, নির্ভরযোগ্য পরামর্শ দেওয়া, কিন্তু বেঞ্চমার্কিংয়ের সময় দেখা গেল যে প্রতিফলন ততটা ধীর নয় যতটা আমি ভেবেছিলাম, LINQ আমার দুঃস্বপ্নের চেয়ে ধীর। কিন্তু শেষ পর্যন্ত দেখা গেল যে আমিও পরিমাপে ভুল করেছি... এই জীবন কাহিনীর বিস্তারিত কাটার নিচে এবং মন্তব্যে রয়েছে। যেহেতু উদাহরণটি বেশ সাধারণ এবং নীতিগতভাবে প্রয়োগ করা হয় যেমনটি সাধারণত একটি এন্টারপ্রাইজে করা হয়, এটি বেশ আকর্ষণীয় হয়ে উঠেছে, যেমনটি আমার কাছে মনে হয়, জীবনের প্রদর্শন: নিবন্ধের মূল বিষয়ের গতির উপর প্রভাব ছিল বাহ্যিক যুক্তির কারণে লক্ষণীয় নয়: Moq, Autofac, EF Core এবং অন্যান্য "ব্যান্ডিং"।

আমি এই নিবন্ধের ছাপের অধীনে কাজ শুরু করেছি: প্রতিফলন ধীর কেন

আপনি দেখতে পাচ্ছেন, লেখক অ্যাপ্লিকেশনটিকে ব্যাপকভাবে গতি বাড়ানোর একটি দুর্দান্ত উপায় হিসাবে সরাসরি প্রতিফলন প্রকারের পদ্ধতিগুলিকে কল করার পরিবর্তে সংকলিত প্রতিনিধিদের ব্যবহার করার পরামর্শ দিয়েছেন। অবশ্যই, আইএল নির্গমন আছে, তবে আমি এটি এড়াতে চাই, যেহেতু এটি কাজটি সম্পাদন করার সবচেয়ে শ্রম-নিবিড় উপায়, যা ত্রুটিতে পরিপূর্ণ।

প্রতিফলনের গতি সম্পর্কে আমি সর্বদা একই মত পোষণ করেছি তা বিবেচনা করে, আমি বিশেষভাবে লেখকের সিদ্ধান্ত নিয়ে প্রশ্ন তোলার ইচ্ছা করিনি।

আমি প্রায়ই এন্টারপ্রাইজে প্রতিফলনের নিষ্পাপ ব্যবহারের সম্মুখীন হই। ধরন নেওয়া হয়। সম্পত্তি সম্পর্কে তথ্য নেওয়া হয়। SetValue পদ্ধতি বলা হয় এবং সবাই আনন্দ করে। টার্গেট ফিল্ডে মান এসেছে, সবাই খুশি। অত্যন্ত বুদ্ধিমান ব্যক্তিরা - সিনিয়র এবং দলের নেতৃত্ব - তাদের এক্সটেনশনগুলি বস্তুতে লিখুন, এই ধরনের একটি নির্বোধ বাস্তবায়নের উপর ভিত্তি করে "সর্বজনীন" ম্যাপার এক প্রকারের থেকে অন্য। সারমর্মটি সাধারণত এই: আমরা সমস্ত ক্ষেত্র গ্রহণ করি, সমস্ত বৈশিষ্ট্য গ্রহণ করি, সেগুলির উপর পুনরাবৃত্তি করি: যদি টাইপ সদস্যদের নাম মিলে যায়, আমরা SetValue কার্যকর করি। সময়ে সময়ে আমরা ভুলের কারণে ব্যতিক্রমগুলি ধরি যেখানে আমরা একটি প্রকারের মধ্যে কিছু সম্পত্তি খুঁজে পাইনি, তবে এখানেও একটি উপায় রয়েছে যা কর্মক্ষমতা উন্নত করে। ধরার চেষ্টা কর.

আমি দেখেছি যে লোকেরা তাদের আগে আসা মেশিনগুলি কীভাবে কাজ করে সে সম্পর্কে সম্পূর্ণরূপে সজ্জিত না হয়েই পার্সার এবং ম্যাপারগুলিকে পুনরায় উদ্ভাবন করে। আমি দেখেছি যে লোকেরা কৌশলগুলির পিছনে, ইন্টারফেসের পিছনে, ইনজেকশনগুলির পিছনে তাদের নিষ্পাপ প্রয়োগগুলিকে লুকিয়ে রাখে, যেন এটি পরবর্তী ব্যাচানালিয়াকে অজুহাত দেয়। আমি এই ধরনের উপলব্ধিতে আমার নাক চালু. প্রকৃতপক্ষে, আমি প্রকৃত কর্মক্ষমতা লিক পরিমাপ করিনি, এবং, যদি সম্ভব হয়, আমি কেবলমাত্র বাস্তবায়নকে আরও "অনুকূল" তে পরিবর্তন করেছি যদি আমি এটিতে হাত পেতে পারি। অতএব, নীচে আলোচনা করা প্রথম পরিমাপগুলি আমাকে গুরুতরভাবে বিভ্রান্ত করেছে।

আমি মনে করি আপনার মধ্যে অনেকেই, রিখটার বা অন্যান্য মতাদর্শী পড়েন, একটি সম্পূর্ণ ন্যায্য বিবৃতিতে এসেছেন যে কোডে প্রতিফলন এমন একটি ঘটনা যা অ্যাপ্লিকেশনটির কার্যকারিতার উপর অত্যন্ত নেতিবাচক প্রভাব ফেলে।

প্রতিফলনকে কল করা CLR কে তাদের প্রয়োজনীয় একটি খুঁজে বের করতে, তাদের মেটাডেটা টানতে, সেগুলিকে পার্স করতে ইত্যাদির জন্য সমাবেশের মধ্য দিয়ে যেতে বাধ্য করে। উপরন্তু, ক্রম অতিক্রম করার সময় প্রতিফলন প্রচুর পরিমাণে মেমরির বরাদ্দের দিকে পরিচালিত করে। আমরা মেমরি ব্যবহার করছি, CLR GC উন্মোচন করে এবং ফ্রিজ শুরু হয়। এটি লক্ষণীয়ভাবে ধীর হওয়া উচিত, আমাকে বিশ্বাস করুন। আধুনিক প্রোডাকশন সার্ভার বা ক্লাউড মেশিনে প্রচুর পরিমাণে মেমরি উচ্চ প্রক্রিয়াকরণ বিলম্ব প্রতিরোধ করে না। আসলে, যত বেশি মেমরি, তত বেশি আপনি লক্ষ্য করবেন যে GC কীভাবে কাজ করে। প্রতিফলন, তাত্ত্বিকভাবে, তার জন্য একটি অতিরিক্ত লাল রাগ।

যাইহোক, আমরা সকলেই IoC কন্টেইনার এবং তারিখ ম্যাপার ব্যবহার করি, যার অপারেটিং নীতিটিও প্রতিফলনের উপর ভিত্তি করে, তবে তাদের কার্যকারিতা সম্পর্কে সাধারণত কোন প্রশ্ন থাকে না। না, নয়, কারণ বাহ্যিক সীমিত প্রসঙ্গ মডেলগুলি থেকে নির্ভরতা এবং বিমূর্তকরণের প্রবর্তন এতই প্রয়োজনীয় যে আমাদের যে কোনও ক্ষেত্রে কর্মক্ষমতা ত্যাগ করতে হবে। সবকিছু সহজ - এটি কার্যকারিতাকে খুব বেশি প্রভাবিত করে না।

আসল বিষয়টি হ'ল প্রতিফলন প্রযুক্তির উপর ভিত্তি করে সবচেয়ে সাধারণ কাঠামোগুলি এটির সাথে আরও ভালভাবে কাজ করার জন্য সমস্ত ধরণের কৌশল ব্যবহার করে। সাধারণত এই একটি ক্যাশে. সাধারণত এগুলি এক্সপ্রেশন এবং এক্সপ্রেশন ট্রি থেকে সংকলিত প্রতিনিধি। একই অটোম্যাপার একটি প্রতিযোগিতামূলক অভিধান রক্ষণাবেক্ষণ করে যা এমন ফাংশনের সাথে মেলে যা প্রতিফলনকে কল না করে একটিকে অন্যটিতে রূপান্তর করতে পারে।

কিভাবে এই অর্জন করা হয়? মূলত, এটি প্ল্যাটফর্ম নিজেই JIT কোড তৈরি করতে ব্যবহার করে এমন যুক্তি থেকে আলাদা নয়। যখন একটি পদ্ধতি প্রথমবার কল করা হয়, তখন এটি কম্পাইল করা হয় (এবং, হ্যাঁ, এই প্রক্রিয়াটি দ্রুত নয়); পরবর্তী কলগুলিতে, নিয়ন্ত্রণ ইতিমধ্যেই সংকলিত পদ্ধতিতে স্থানান্তরিত হয় এবং কোন উল্লেখযোগ্য কর্মক্ষমতা ড্রডাউন হবে না।

আমাদের ক্ষেত্রে, আপনি JIT সংকলনও ব্যবহার করতে পারেন এবং তারপরে এর AOT সমকক্ষগুলির মতো একই কর্মক্ষমতা সহ সংকলিত আচরণ ব্যবহার করতে পারেন। অভিব্যক্তি এই ক্ষেত্রে আমাদের সাহায্যে আসবে.

প্রশ্নে থাকা নীতিটি সংক্ষেপে নিম্নরূপ প্রণয়ন করা যেতে পারে:
আপনার সংকলিত ফাংশন ধারণকারী প্রতিনিধি হিসাবে প্রতিফলনের চূড়ান্ত ফলাফল ক্যাশে করা উচিত। আপনার টাইপ, কর্মী, যেগুলি অবজেক্টের বাইরে সংরক্ষিত আছে তার ক্ষেত্রে টাইপ তথ্য সহ সমস্ত প্রয়োজনীয় বস্তু ক্যাশে করাও বোধগম্য।

এর মধ্যে যুক্তি আছে। সাধারণ জ্ঞান আমাদের বলে যে যদি কিছু সংকলন এবং ক্যাশে করা যায় তবে তা করা উচিত।

সামনের দিকে তাকিয়ে, এটা বলা উচিত যে প্রতিফলনের সাথে কাজ করার ক্যাশে এর সুবিধা রয়েছে, এমনকি যদি আপনি অভিব্যক্তি সংকলনের প্রস্তাবিত পদ্ধতি ব্যবহার না করেন। আসলে, এখানে আমি কেবল নিবন্ধটির লেখকের থিসিসগুলি পুনরাবৃত্তি করছি যা আমি উপরে উল্লেখ করেছি।

এখন কোড সম্পর্কে। আসুন একটি উদাহরণ দেখি যা আমার সাম্প্রতিক ব্যথার উপর ভিত্তি করে যা আমাকে একটি গুরুতর ক্রেডিট প্রতিষ্ঠানের গুরুতর উত্পাদনের মুখোমুখি হতে হয়েছিল। সমস্ত সত্তা কাল্পনিক যাতে কেউ অনুমান না করে।

কিছু সারমর্ম আছে। যোগাযোগ হতে দিন. একটি প্রমিত বডি সহ অক্ষর রয়েছে, যা থেকে পার্সার এবং হাইড্রেটর একই পরিচিতিগুলি তৈরি করে। একটি চিঠি এসেছিল, আমরা এটি পড়েছি, এটিকে কী-মান জোড়ায় পার্স করেছি, একটি পরিচিতি তৈরি করেছি এবং ডাটাবেসে সংরক্ষণ করেছি।

এটা প্রাথমিক. ধরা যাক একটি পরিচিতির সম্পূর্ণ নাম, বয়স এবং যোগাযোগের ফোন বৈশিষ্ট্য রয়েছে। এই তথ্য চিঠিতে প্রেরণ করা হয়. চিঠির মূল অংশে জোড়ায় সত্তা বৈশিষ্ট্য ম্যাপ করার জন্য দ্রুত নতুন কী যোগ করতে সক্ষম হওয়ার জন্য ব্যবসাটি সমর্থন চায়। যদি কেউ টেমপ্লেটে একটি টাইপো করে থাকে বা রিলিজের আগে জরুরীভাবে একটি নতুন অংশীদার থেকে ম্যাপিং চালু করা প্রয়োজন, নতুন বিন্যাসে অভিযোজিত। তারপরে আমরা একটি সস্তা ডেটাফিক্স হিসাবে একটি নতুন ম্যাপিং পারস্পরিক সম্পর্ক যুক্ত করতে পারি। অর্থাৎ জীবনের উদাহরণ।

আমরা বাস্তবায়ন করি, পরীক্ষা তৈরি করি। কাজ করে।

আমি কোডটি সরবরাহ করব না: প্রচুর উত্স রয়েছে এবং সেগুলি নিবন্ধের শেষে লিঙ্কের মাধ্যমে গিটহাবে উপলব্ধ। আপনি তাদের লোড করতে পারেন, স্বীকৃতির বাইরে তাদের নির্যাতন করতে পারেন এবং তাদের পরিমাপ করতে পারেন, কারণ এটি আপনার ক্ষেত্রে প্রভাব ফেলবে। আমি শুধুমাত্র দুটি টেমপ্লেট পদ্ধতির কোড দেব যা হাইড্রেটরকে আলাদা করে, যা দ্রুত হওয়ার কথা ছিল, হাইড্রেটর থেকে, যা ধীর হওয়ার কথা ছিল।

যুক্তিটি নিম্নরূপ: টেমপ্লেট পদ্ধতি মৌলিক পার্সার যুক্তি দ্বারা উত্পন্ন জোড়া গ্রহণ করে। 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;
        }

এখানে আমরা অবিলম্বে বৈশিষ্ট্য বাইপাস এবং সরাসরি SetValue কল.

স্পষ্টতার জন্য এবং একটি রেফারেন্স হিসাবে, আমি একটি সরল পদ্ধতি প্রয়োগ করেছি যা সরাসরি সত্তা ক্ষেত্রগুলিতে তাদের পারস্পরিক সম্পর্ক জোড়ার মানগুলি লেখে। উপসর্গ - ম্যানুয়াল।

এখন বেঞ্চমার্কডটনেট নেওয়া যাক এবং কর্মক্ষমতা পরীক্ষা করা যাক। এবং হঠাৎ... (স্পয়লার - এটি সঠিক ফলাফল নয়, বিশদ নীচে রয়েছে)

আমরা এখানে কি দেখতে পাচ্ছি? যে পদ্ধতিগুলি বিজয়ীভাবে দ্রুত উপসর্গ বহন করে সেগুলি প্রায় সমস্ত পাসেই ধীর উপসর্গ সহ পদ্ধতিগুলির তুলনায় ধীর হতে দেখা যায়৷ এটি কাজের বরাদ্দ এবং গতি উভয়ের জন্যই সত্য। অন্যদিকে, যেখানে সম্ভব সেখানে LINQ পদ্ধতি ব্যবহার করে ম্যাপিংয়ের একটি সুন্দর এবং মার্জিত বাস্তবায়ন, এর বিপরীতে, উত্পাদনশীলতাকে ব্যাপকভাবে হ্রাস করে। পার্থক্যটি অর্ডারের। পাসের বিভিন্ন নম্বর দিয়ে প্রবণতা পরিবর্তন হয় না। পার্থক্য শুধু স্কেলে। LINQ এর সাথে এটি 4 - 200 গুণ ধীর, প্রায় একই স্কেলে আরও আবর্জনা রয়েছে।

আপডেট

আমি আমার চোখকে বিশ্বাস করিনি, তবে আরও গুরুত্বপূর্ণ, আমাদের সহকর্মী আমার চোখ বা আমার কোডকে বিশ্বাস করেননি - দিমিত্রি টিখোনভ 0x1000000. আমার সমাধান দুবার চেক করার পরে, তিনি উজ্জ্বলভাবে একটি ত্রুটি আবিষ্কার করেছেন এবং নির্দেশ করেছেন যেটি আমি বাস্তবায়নে কিছু পরিবর্তনের কারণে মিস করেছি, প্রাথমিক থেকে চূড়ান্ত। Moq সেটআপে পাওয়া বাগটি ঠিক করার পরে, সমস্ত ফলাফল ঠিক হয়ে গেছে। পুনঃপরীক্ষার ফলাফল অনুসারে, প্রধান প্রবণতা পরিবর্তন হয় না - LINQ এখনও প্রতিফলনের চেয়ে কর্মক্ষমতাকে বেশি প্রভাবিত করে। যাইহোক, এটা চমৎকার যে এক্সপ্রেশন কম্পাইল করার কাজটি বৃথা হয়নি, এবং ফলাফল বরাদ্দ এবং কার্যকর করার সময় উভয় ক্ষেত্রেই দৃশ্যমান। প্রথম প্রবর্তন, যখন স্থির ক্ষেত্রগুলি শুরু করা হয়, স্বাভাবিকভাবেই "দ্রুত" পদ্ধতির জন্য ধীর, কিন্তু তারপর পরিস্থিতি পরিবর্তিত হয়।

এখানে পুনরায় পরীক্ষার ফলাফল:

উপসংহার: একটি এন্টারপ্রাইজে প্রতিফলন ব্যবহার করার সময়, কৌশল অবলম্বন করার কোনও বিশেষ প্রয়োজন নেই - LINQ উত্পাদনশীলতাকে আরও বাড়িয়ে তুলবে। যাইহোক, অপ্টিমাইজেশানের প্রয়োজন উচ্চ-লোড পদ্ধতিতে, আপনি ইনিশিয়ালাইজার এবং ডেলিগেট কম্পাইলার আকারে প্রতিফলন সংরক্ষণ করতে পারেন, যা তারপরে "দ্রুত" যুক্তি প্রদান করবে। এইভাবে আপনি প্রতিফলনের নমনীয়তা এবং অ্যাপ্লিকেশনের গতি উভয়ই বজায় রাখতে পারেন।

বেঞ্চমার্ক কোড এখানে উপলব্ধ. যে কেউ আমার কথাগুলো দুবার চেক করতে পারেন:
হ্যাব্রা রিফ্লেকশন টেস্ট

PS: পরীক্ষার কোডটি IoC ব্যবহার করে, এবং বেঞ্চমার্কগুলিতে এটি একটি স্পষ্ট গঠন ব্যবহার করে। আসল বিষয়টি হ'ল চূড়ান্ত বাস্তবায়নে আমি কার্যক্ষমতাকে প্রভাবিত করতে পারে এবং ফলাফলকে গোলমাল করতে পারে এমন সমস্ত কারণকে কেটে দিয়েছি।

PPS: ব্যবহারকারীকে ধন্যবাদ দিমিত্রি টিখোনভ @0x1000000 Moq সেট আপ করার ক্ষেত্রে আমার ত্রুটি আবিষ্কার করার জন্য, যা প্রথম পরিমাপকে প্রভাবিত করেছিল। পাঠকদের মধ্যে যদি যথেষ্ট কর্মফল থাকে, দয়া করে এটি পছন্দ করুন। লোকটি থেমে গেল, লোকটি পড়ল, লোকটি দুবার চেক করে ভুলটি দেখিয়ে দিল। আমি মনে করি এটি সম্মান ও সহানুভূতির যোগ্য।

PPPS: সূক্ষ্ম পাঠককে ধন্যবাদ যারা শৈলী এবং নকশার নীচে পৌঁছেছেন। আমি অভিন্নতা এবং সুবিধার জন্য. উপস্থাপনার কূটনীতি কাঙ্ক্ষিত হতে অনেক ছেড়ে, কিন্তু আমি অ্যাকাউন্টে সমালোচনা গ্রহণ. আমি প্রক্ষিপ্ত জন্য জিজ্ঞাসা.

উত্স: www.habr.com