[...] (মাইক্রোসেকেন্ড পরিবেশে অনুমোদিত) [...]
আমরা যদি কয়েক মিলিয়ন থেকে কোটি কোটি জিনিস লুপ করে থাকি তবে মাইক্রো-সেকেন্ড যুক্ত হয়। সি ++ (ব্যক্তিগতভাবে কোনও অ্যালগরিদমিক উন্নতি নেই) থেকে একটি ব্যক্তিগত ভিটিউন / মাইক্রো-অপ্টিমাইজেশন সেশন:
T-Rex (12.3 million facets):
Initial Time: 32.2372797 seconds
Multithreading: 7.4896073 seconds
4.9201039 seconds
4.6946372 seconds
3.261677 seconds
2.6988536 seconds
SIMD: 1.7831 seconds
4-valence patch optimization: 1.25007 seconds
0.978046 seconds
0.970057 seconds
0.911041 seconds
"মাল্টিথ্রেডিং", "সিমডি" (সংকলককে হিট করার জন্য লিখিত) এবং 4-ভ্যালেন্স প্যাচ অপ্টিমাইজেশানটি মাইক্রো-লেভেলের মেমরি অপ্টিমাইজেশান ছিল। এছাড়াও 32 সেকেন্ডের প্রাথমিক সময় থেকে শুরু হওয়া মূল কোডটি ইতিমধ্যে বেশ কিছুটা অপ্টিমাইজ করা হয়েছিল (তাত্ত্বিকভাবে- অনুকূল আলগোরিদিম জটিলতা) এবং এটি সাম্প্রতিক একটি অধিবেশন। মূল সংস্করণটি সাম্প্রতিক অধিবেশনটি প্রক্রিয়া করতে 5 মিনিটের বেশি সময় নিয়েছে।
মেমরি দক্ষতার অপ্টিমাইজ করা প্রায়শই যেকোন সময় থেকে একক থ্রেডযুক্ত প্রেক্ষাপটে বিশাল আকারের অর্ডারগুলিতে এবং মাল্টিথ্রেডযুক্ত প্রসঙ্গে আরও অনেকগুলি সহায়তা করতে পারে (দক্ষ মেমরির প্রতিনিধির সুবিধাগুলি প্রায়শই মিশ্রণের একাধিক থ্রেডের সাথে গুণ করে)।
মাইক্রো-অপটিমাইজেশনের গুরুত্বের উপর
এই ধারণাটি নিয়ে আমি কিছুটা বিরক্ত হই যে মাইক্রো-অপ্টিমাইজেশানগুলি সময় নষ্ট করে a আমি সম্মত হই যে এটি ভাল সাধারণ পরামর্শ, তবে সকলেই এটি পরিমাপের পরিবর্তে শিকার এবং কুসংস্কারের ভিত্তিতে ভুলভাবে করে না। সঠিকভাবে সম্পন্ন হয়েছে, এটি অগত্যা কোনও মাইক্রো ইফেক্ট দেয় না। যদি আমরা ইন্টেলের নিজস্ব এমব্রি (রাইক্র্যাকিং কার্নেল) নিই এবং কেবলমাত্র তারা যে সহজ স্কেলার বিভিএইচ লিখেছেন তা পরীক্ষা করে নিই (রে প্যাকেটটি যা মারতে তাত্পর্যপূর্ণভাবে শক্ত) না, এবং তারপরে সেই ডেটা স্ট্রাকচারের কার্যকারিতাটি হারাতে চেষ্টা করা গেলে এটি সবচেয়ে বেশি হতে পারে এমনকি কয়েক দশক ধরে প্রফুলিং এবং টিউনিং কোড ব্যবহার করার জন্য অভিজ্ঞ একজন অভিজ্ঞের কাছেও নম্র অভিজ্ঞতা। এবং এটি মাইক্রো-অপ্টিমাইজেশান প্রয়োগের কারণে। তাদের সমাধানটি প্রতি সেকেন্ডে এক মিলিয়ন রশ্মি রশ্মি প্রক্রিয়াকরণ করতে পারে যখন আমি শিল্প পেশাদাররা দেখেছি যে রাইট্রেসিংয়ে কাজ করছে যারা '
কেবলমাত্র একটি অ্যালগোরিদমিক ফোকাস সহ কোনও বিভিএইচ-এর সরাসরি প্রয়োগের উপায় নেই এবং কোনও অপ্টিমাইজ করা সংকলক (এমনকি ইন্টেলের নিজস্ব আইসিসি) এর বিপরীতে প্রতি সেকেন্ডে একশ মিলিয়ন প্রাথমিক রে ছেদ পাওয়া যায় না। সোজা একটি প্রায়শই প্রতি সেকেন্ডে মিলিয়ন রশ্মিও পায় না। এটি প্রায়শই প্রতি সেকেন্ডে কয়েক মিলিয়ন রশ্মি পেতে পেশাদার মানের সমাধান নেয়। প্রতি সেকেন্ডে একশ মিলিয়ন রশ্মি পেতে ইন্টেল-স্তরের মাইক্রো-অপটিমাইজেশন লাগে।
আলগোরিদিম
আমি মনে করি যতক্ষণ না মিনিট থেকে সেকেন্ডের পর্যায়ে যেমন ঘন্টা বা কয়েক ঘন্টা থেকে মিনিট পর্যন্ত কর্মক্ষমতা গুরুত্বপূর্ণ নয় ততক্ষণ মাইক্রো অপ্টিমাইজেশন গুরুত্বপূর্ণ নয়। যদি আমরা বুদ্বুদ সাজানোর মতো ভয়াবহ অ্যালগরিদম গ্রহণ করি এবং এটি একটি উদাহরণ হিসাবে একটি ভর ইনপুট ধরে ব্যবহার করি, এবং তারপরে এটি মার্জ সাজানোর এমনকি একটি প্রাথমিক প্রয়োগের সাথে তুলনা করি, ফলস্বরূপ প্রসেসটি কয়েক মাস সময় নিতে পারে, সম্ভবত পরবর্তী 12 মিনিট হতে পারে চতুর্ভুজ বনাম লিনিয়ারীথমিক জটিলতা।
মাস এবং মিনিটের মধ্যে পার্থক্য সম্ভবত বেশিরভাগ লোককে তৈরি করতে চলেছে, এমনকি যারা পারফরম্যান্স-সমালোচনামূলক ক্ষেত্রেও কাজ করে না, মৃত্যুদন্ড কার্যকর করার সময়টিকে অগ্রহণযোগ্য বলে বিবেচনা করে যদি ফলাফল পেতে কয়েক মাস অপেক্ষা করা ব্যবহারকারীদের প্রয়োজন হয়।
এদিকে, আমরা যদি অ-মাইক্রো-অপ্টিমাইজড, স্ট্রেফওয়ার্ড মার্জ সাজ্টকে কুইকোর্টের সাথে তুলনা করি (যা মার্জ সাজানোর তুলনায় কোনওভাবেই অ্যালগরিদমিকভাবে উচ্চতর নয়, এবং কেবলমাত্র রেফারেন্সের স্থানীয়তার জন্য মাইক্রো-লেভেল উন্নতি সরবরাহ করে), মাইক্রো-অপ্টিমাইজড কোউকোর্টটি শেষ হতে পারে 15 মিনিটের বিপরীতে 15 সেকেন্ড। ব্যবহারকারীদের 12 মিনিটের জন্য অপেক্ষা করা পুরোপুরি গ্রহণযোগ্য হতে পারে (বেশিরভাগ সময় কফি বিরতি)।
আমি মনে করি যে এই পার্থক্যটি সম্ভবত 12 মিনিট এবং 15 সেকেন্ডের মধ্যে বেশিরভাগ লোকের কাছেই নগণ্য, এবং তাই মাইক্রো-অপ্টিমাইজেশন প্রায়শই অকেজো বলে বিবেচিত হয় কারণ এটি প্রায়শই মিনিট এবং সেকেন্ডের মধ্যে হয়, এবং কয়েক মিনিট এবং মাসের মধ্যে নয় difference অন্য যে কারণে আমি এটি অকেজো বলে মনে করি তা হ'ল এটি প্রায়শই এমন ক্ষেত্রে প্রয়োগ করা হয় যা কিছু যায় আসে না: কিছু ছোট অঞ্চল যা লুপি এবং সমালোচনামূলক নয় যা কিছু প্রশ্নযুক্ত 1% পার্থক্য দেয় (যা খুব ভাল কেবল শব্দ হতে পারে)। তবে যারা এই সময়ের সময়ের পার্থক্যের বিষয়ে যত্নশীল হন এবং এটি সঠিকভাবে পরিমাপ করতে এবং ঠিক করতে রাজি হন তাদের জন্য আমি মনে করি এটি কমপক্ষে মেমরি শ্রেণিবদ্ধের প্রাথমিক ধারণাগুলিতে (বিশেষত পৃষ্ঠার ত্রুটিগুলি এবং ক্যাশে মিস করা সম্পর্কিত উচ্চ স্তরের) দিকে মনোযোগ দেওয়া উচিত worth ।
জাভা ভাল মাইক্রো-অপ্টিমাইজেশনের জন্য প্রচুর ঘর ফেলেছে
ভাই, দুঃখিত - এই ধরণের অভিমানের পাশাপাশি:
JVM এর "যাদু" জাভাতে মাইক্রো-অপটিমাইজেশনের উপর কোনও প্রোগ্রামারের প্রভাবকে বাধা দেয়?
আপনি যদি এটি সঠিকভাবে করেন তবে লোকেরা যতটুকু ভাবতে পারে তেমন কিছু নয়। উদাহরণস্বরূপ, আপনি যদি হস্তাক্ষর সিমডি, মাল্টিথ্রেডিং এবং মেমরি অপটিমাইজেশন (অ্যাক্সেস প্যাটার্ন এবং চিত্রের প্রসেসিং অ্যালগরিদমের উপর নির্ভর করে সম্ভবত উপস্থাপনা) সহ স্থানীয় কোডে চিত্র প্রক্রিয়াকরণটি করেন তবে 32- এর জন্য প্রতি সেকেন্ডে কয়েক মিলিয়ন পিক্সেল ক্রঞ্চ করা সহজ easy বিট আরজিবিএ পিক্সেল (8-বিট রঙ চ্যানেল) এবং কখনও কখনও প্রতি সেকেন্ডে বিলিয়নও।
জাভাতে আর কোথাও পৌঁছানো অসম্ভব যদি আপনি বলেন, কোনও Pixelবস্তু তৈরি করেছেন (এটি একা পিক্সেলের আকার 4 বাইট থেকে 16 বিট পর্যন্ত 64-বিট বাড়িয়ে তুলবে)।
আপনি যদি Pixelবস্তুটি এড়িয়ে যান , বাইটের একটি অ্যারে ব্যবহার করেন এবং কোনও Imageবস্তুকে মডেল করেন তবে আপনি সম্ভবত পুরোটা খুব কাছাকাছি পেতে সক্ষম হতে পারেন । জাভা এখনও সেখানে বেশ দক্ষ যদি আপনি সরল পুরানো ডেটার অ্যারে ব্যবহার শুরু করেন। আমি জাভাতে আগে এই ধরণের জিনিসগুলি চেষ্টা করেছি এবং বেশ প্রভাবিত হয়েছি তবে আপনি যে কোনও জায়গায় ছোট ছোট কিশোর বস্তুগুলি যে কোনও জায়গার চেয়ে স্বাভাবিকের চেয়ে 4 গুণ বড় (উদাহরণস্বরূপ: intপরিবর্তে ব্যবহার করুন Integer) তৈরি করবেন না এবং বাল্কের ইন্টারফেসগুলির মতো মডেলিং শুরু করবেন না providedImage ইন্টারফেস, ইন্টারফেস নয় Pixel। এমনকি আপনি যদি বলতে পারেন যে জাভা সি ++ পারফরম্যান্সকে প্রতিদ্বন্দ্বিতা করতে পারে তবে যদি আপনি সরল পুরানো ডেটা লুপ করেন এবং অবজেক্টস না ( floatযেমন বিশাল অ্যারে , যেমন না Float))
মেমরির আকারগুলির চেয়ে আরও গুরুত্বপূর্ণ এটি হ'ল একটি অ্যারে intএকটি প্রতিনিধিত্বমূলক প্রতিনিধিত্বের গ্যারান্টি দেয়। একটি অ্যারে Integerনা। রেফারেন্সের স্থানীয়তার জন্য প্রায়শই সাবলীলতা আবশ্যক, কারণ এর অর্থ একাধিক উপাদান (উদা: ১ intsall) সমস্ত একক ক্যাশে লাইনে ফিট করতে পারে এবং দক্ষ মেমরি অ্যাক্সেস প্যাটার্নগুলির সাথে উচ্ছেদের আগে সম্ভাব্যভাবে একসাথে অ্যাক্সেস করা যেতে পারে। ইতিমধ্যে কোনও একক Integerস্মৃতিতে অন্য কোথাও আটকে থাকতে পারে পার্শ্ববর্তী স্মৃতি অপ্রাসঙ্গিক, কেবলমাত্র 16 টি পূর্ণসংখ্যার বিপরীতে উচ্ছেদের পূর্বে একটি একক পূর্ণসংখ্যার ব্যবহারের জন্য কেবল মেমরির অঞ্চলটি ক্যাশে লাইনে লোড করা হয়। এমনকি যদি আমরা দুর্দান্তভাবে ভাগ্যবান এবং চারপাশে পেয়েছিIntegersমেমরির ক্ষেত্রে একে অপরের পাশে ঠিক ছিলাম, আমরা কেবল 4 টি ক্যাশে লাইনে ফিট করতে পারি Integerযা 4 গুণ বড় হওয়ার ফলস্বরূপ উচ্ছেদের আগে অ্যাক্সেস করা যায় এবং এটি সর্বোত্তম ক্ষেত্রে রয়েছে।
এবং একই মেমরি আর্কিটেকচার / শ্রেণিবিন্যাসের অধীনে আমরা একত্রিত হওয়ার পরে সেখানে প্রচুর পরিমাণে মাইক্রো-অপ্টিমাইজেশন রয়েছে। মেমোরি অ্যাক্সেসের নিদর্শনগুলি আপনি যে কোনও ভাষা ব্যবহার করুন না কেন, লুপ টাইলিং / ব্লক করার মত ধারণাগুলি সাধারণত সি বা সি ++ এ প্রায়শই প্রায়শই প্রয়োগ করা যেতে পারে তবে তারা জাভাটিকে ততটা উপকৃত করে।
আমি সম্প্রতি সি ++ এ পড়েছি কখনও কখনও ডেটা সদস্যদের ক্রমটি অপ্টিমাইজেশন সরবরাহ করতে পারে [...]
ডেটা সদস্যদের ক্রম জাভাতে সাধারণত কিছু যায় আসে না, তবে এটি বেশিরভাগই ভাল জিনিস। সি এবং সি ++-তে, ডেবি সদস্যদের ক্রম সংরক্ষণ করা এবিআই কারণে প্রায়শই গুরুত্বপূর্ণ কারণ সংকলকরা এতে গণ্ডগোল করেন না। সেখানে কর্মরত মানব বিকাশকারীদের প্যাডিংয়ের স্মৃতিশক্তি নষ্ট না করার জন্য তাদের ডেটা সদস্যদের অবতরণ ক্রমে (বৃহত্তম থেকে ক্ষুদ্রতম) সজ্জিত করার মতো জিনিসগুলি করতে সাবধানতা অবলম্বন করতে হবে। জাভা সহ, স্পষ্টতই জেআইডি আপনার জন্য প্যাডিং হ্রাস করার সময় যথাযথ প্রান্তিককরণ নিশ্চিত করার জন্য ফ্লাইতে সদস্যদের পুনরায় সাজিয়ে তুলতে পারে, তবে এটির ক্ষেত্রে যদি এটি থাকে তবে এটি গড় সি এবং সি ++ প্রোগ্রামারগুলিকে প্রায়শই দুর্বল করতে পারে এবং মেমরি নষ্ট করে দেয় এমনভাবে শেষ করে ( যা কেবল স্মৃতিশক্তি নষ্ট করে না, তবে প্রায়শই অযৌক্তিকভাবে এওএস কাঠামোর মধ্যে ক্রম বাড়িয়ে এবং আরও ক্যাশে মিস করে) গতি নষ্ট করে। এটা ' প্যাডিং কমানোর জন্য ক্ষেত্রগুলি পুনরায় সাজানোর জন্য খুব রোবোটিক জিনিস, তাই আদর্শভাবে মানুষ এর সাথে ডিল করেন না। একমাত্র সময় যেখানে ক্ষেত্রের ব্যবস্থা এমনভাবে হয়ে উঠতে পারে যাতে কোনও মানুষের জন্য সর্বোত্তম বিন্যাসটি জানতে হবে যদি বস্তুটি by৪ বাইটের চেয়ে বড় হয় এবং আমরা অ্যাক্সেস প্যাটার্নের ভিত্তিতে ক্ষেত্রগুলি সাজিয়ে থাকি (অনুকূল প্যাডিং নয়) - তবে এটি ক্ষেত্রে আরও বেশি মানুষের প্রচেষ্টা হতে পারে (সমালোচনামূলক পাথগুলি বোঝার প্রয়োজন হয় যার মধ্যে কয়েকটি এমন তথ্য যা ব্যবহারকারীরা সফ্টওয়্যারটি দিয়ে কী করবে তা জেনেও সংকলক সম্ভবত ধারণা করতে পারে না)।
যদি তা না হয় তবে লোকেরা জাভাতে আপনি কী কৌশল ব্যবহার করতে পারেন তার উদাহরণ দিতে পারে (সাধারণ সংকলক পতাকা ছাড়াও)।
জাভা এবং সি ++ এর মধ্যে অনুকূলকরণের মানসিকতার ক্ষেত্রে আমার কাছে সবচেয়ে বড় পার্থক্য হ'ল সি ++ আপনাকে পারফরম্যান্স-সমালোচনামূলক দৃশ্যে জাভা থেকে কিছুটা (কিশোরী) কিছুটা বেশি ব্যবহার করতে দেয়। উদাহরণস্বরূপ, সি ++ কোনও শ্রেণীর সাথে একটি পূর্ণসংখ্যা গুটিয়ে ফেলতে পারে যা কোনও ওভারহেড ছাড়াই (পুরো জায়গা জুড়ে বেঞ্চমার্কযুক্ত)। জাভাতে সেই মেটাডেটা পয়েন্টার-স্টাইল + প্রান্তিককরণ প্যাডিং ওভারহেড থাকতে হবে যা এজন্যই Booleanবড় boolean(তবে প্রতিফলনের অভিন্ন সুবিধা প্রদান এবং কোনও finalএকক ইউডিটির জন্য চিহ্নিত নয় এমন কোনও ক্রিয়াকে ওভাররাইড করার ক্ষমতা প্রদানের বিনিময়ে )।
অ-সমজাতীয় ক্ষেত্রগুলি জুড়ে মেমরি লেআউটের স্বাতন্ত্র্য নিয়ন্ত্রণ করতে সি ++ এ কিছুটা সহজ easier জাভায় যখন জিসির মাধ্যমে অবজেক্টগুলি বরাদ্দ করা হয়।
... তবে প্রায়শই সর্বাধিক-সম্পাদনা সমাধানগুলি যে কোনও উপায়ে বিভক্ত হয়ে যায় এবং সাধারণ পুরানো ডেটার সংমিশ্রিত অ্যারেগুলির উপরে একটি SoA অ্যাক্সেস প্যাটার্ন ব্যবহার করে। সুতরাং যে জায়গাগুলি শীর্ষে পারফরম্যান্স প্রয়োজন তাদের জন্য জাভা এবং সি ++ এর মধ্যে মেমরি লেআউট অনুকূলিতকরণের কৌশলগুলি প্রায়শই একই রকম হয় এবং প্রায়শই আপনি সংগ্রহ-শৈল ইন্টারফেসের পক্ষে সেই কিশোরী অবজেক্ট-ভিত্তিক ইন্টারফেসগুলি ধ্বংস করে যা গরম / এর মতো জিনিসগুলি করতে পারে / ঠাণ্ডা ক্ষেত্র বিভাজন, এসএএ রেপস ইত্যাদি। অ-সমজাতীয় অওসোএ রেপগুলি জাভাতে একধরণের অসম্ভব বলে মনে হচ্ছে (যদি না আপনি কেবলমাত্র বাইটের কাঁচা অ্যারে বা এমন কিছু ব্যবহার করেন) তবে এগুলি বিরল ক্ষেত্রে যেখানে উভয়ইক্রমবর্ধমান এবং এলোমেলো অ্যাক্সেস নিদর্শনগুলি একই সাথে গরম ক্ষেত্রের জন্য ক্ষেত্রের ধরণের মিশ্রণ থাকা দ্রুত হওয়া দরকার। আমার পক্ষে যদি আপনি শীর্ষের পারফরম্যান্সে পৌঁছাচ্ছেন তবে এই দুটিয়ের মধ্যে অপ্টিমাইজেশান কৌশলের (সাধারণ ধরণের স্তরের) পার্থক্যের বেশিরভাগ অংশটিই মুখ্য।
পার্থক্য আরো বেশ একটু পরিবর্তিত হতে যদি আপনি কেবল "ভালো" পারফরম্যান্সের জন্য পৌঁছনো হয় - মত ছোট বস্তুর সঙ্গে যতটা না করতে পারবে না Integerবনাম intবিশেষত উপায় এটা জেনেরিক্স সাথে মিথস্ক্রিয়া সঙ্গে একটি Pita একটি বিট আরো হতে পারে, । এটা তোলে জাভা একটি কেন্দ্রীয় অপ্টিমাইজেশান লক্ষ্য শুধু বিল্ড এক জেনেরিক ডাটা স্ট্রাকচার করার জন্য একটি বিট কঠিন যে জন্য কাজ int, floatইত্যাদি যখন ঐ বড় এবং ব্যয়বহুল UDTs এড়ানো, কিন্তু প্রায়ই সবচেয়ে কর্মক্ষমতা-সমালোচনামূলক এলাকায় হাত-রোলিং আপনার নিজের ডাটা স্ট্রাকচার প্রয়োজন হবে যাইহোক যাইহোক একটি খুব নির্দিষ্ট উদ্দেশ্যে সুরযুক্ত তাই এটি কেবল কোডের জন্য বিরক্তিকর যা ভাল পারফরম্যান্সের জন্য চেষ্টা করছে তবে পিক পারফরম্যান্সের জন্য নয়।
ওভারহেড অবজেক্ট
নোট করুন যে জাভা অবজেক্ট ওভারহেড (স্থানীয় জিসি চক্রের পরে স্থানীয় স্থানীয়ত্বের মেটাডাটা এবং ক্ষতি এবং অস্থায়ী লোকাল অস্থায়ী ক্ষতি) প্রায়শই এমন জিনিসগুলির জন্য বড় যেগুলি সত্যই ছোট (যেমন intবনাম Integer) এমন কিছু জিনিস যা লক্ষ লক্ষ লোকেরা কিছু ডেটা স্ট্রাকচারে সংরক্ষণ করে being অত্যন্ত সংক্ষিপ্ত এবং খুব টাইট লুপগুলিতে অ্যাক্সেস করা। এই বিষয়টি সম্পর্কে অনেক সংবেদনশীলতা রয়েছে বলে মনে হচ্ছে, সুতরাং আমার স্পষ্ট করে বলা উচিত যে আপনি চিত্রগুলির মতো বড় অবজেক্টের জন্য অবজেক্ট ওভারহেড সম্পর্কে উদ্বিগ্ন হতে চান না, কেবলমাত্র একটি একক পিক্সেলের মতো বিস্মৃত বস্তুগুলি।
যদি কেউ এই অংশ সম্পর্কে সন্দেহ অনুভব করেন তবে আমি এক মিলিয়ন র্যান্ডম intsবনাম দশ মিলিয়ন র্যান্ডম যোগফলের মাঝে একটি বার্তা তৈরি করার পরামর্শ দিচ্ছি এবং Integersবারবার এটি করার জন্য ( Integersপ্রাথমিক জিসি চক্রের পরে স্মৃতিতে রদবদল হবে)।
চূড়ান্ত ট্রিক: ইন্টারফেস ডিজাইনগুলি অনুকূলিতকরণের জন্য ঘর ছেড়ে দেয়
সুতরাং চূড়ান্ত জাভা ট্রিক হিসাবে আমি এটি দেখতে পাচ্ছি যদি আপনি এমন কোনও জায়গার সাথে কথা বলছেন যা ছোট ছোট বস্তুর উপর ভারী বোঝা পরিচালনা করে (উদা: একটি Pixel, একটি 4-ভেক্টর, 4x4 ম্যাট্রিক্স, একটি Particle, সম্ভবত এমনকি Accountযদি এটিতে কেবল কয়েকটি ছোট থাকে) ক্ষেত্রগুলি) এই কিশোর জিনিসগুলির জন্য অবজেক্টগুলি ব্যবহার এড়াতে এবং প্লেইন পুরানো ডেটার অ্যারেগুলি (সম্ভবত এক সাথে বেড়ানো) ব্যবহার করা। বস্তুগুলি তারপরে Image, ম্যাট্রিক বা ভেক্টর ইত্যাদির সংগ্রহ যেমন , সংগ্রহের ইন্টারফেসে পরিণত হয় ParticleSystem, Accountsপৃথকগুলি সূচক দ্বারা অ্যাক্সেস করা যায়, উদাহরণস্বরূপ এটি সি এবং সি ++ এর চূড়ান্ত নকশার কৌশলগুলির মধ্যে একটি, যেহেতু সেই মৌলিক অবজেক্ট ছাড়াই এবং একচেটিয়া কণার স্তরে ইন্টারফেসকে মডেলিং করা মঞ্জুরিযুক্ত না হওয়া, সবচেয়ে কার্যকর সমাধানগুলিকে বাধা দেয়।