تحياتي يا غوفرز! خلال السنة الأولى من العمل مع Golang، ظللت أفكر أنه يجب أن يكون هناك ترتيب للحقول وفكرت لماذا يجب أن أنزعج بشأن ذلك؟ حسنًا، إنها مجرد حقول، فقط يمكن أن يكون هناك خطأ ما، أليس كذلك؟ مثل معظم المبتدئين الآخرين، اعتقدت أن الأمر لا يستحق الاهتمام به. بمعنى آخر، ما مدى أهمية وضع حقول معينة في البنية بترتيب معين؟ حسنًا، صفقة رائعة!

يعد ترتيب الحقول أحد الجوانب التي تم تجاهلها في البداية ولكن مع استمرار المرء في البرنامج التعليمي، يُفهم هذا الفهم بشكل خاص لكيفية عمل Go مع المؤشرات على أنه أمر بالغ الأهمية. في الواقع، يعد هذا الترتيب بالتحديد أمرًا بالغ الأهمية عندما يتعلق الأمر بتحسين أداء التطبيق، خاصة عند العمل مع مجموعات كبيرة من البيانات أو العمليات التي تكون ثقيلة جدًا على الذاكرة. سيتم إصلاح هذا النقص المؤسف من خلال فهم أفضل لسبب أهميته الشديدة في الطلب الميداني لـ Go.

كيف يتم تخزين الهياكل في الذاكرة؟

عند وضعها في الذاكرة، يتم تمثيل البنيات ككتلة من الذاكرة المتتالية، حيث توجد جميع الحقول واحدًا تلو الآخر وفقًا لتعريفها في البنية. قد يبدو هذا بسيطًا إلى حد ما، لكن هذا النوع من التنظيم الخطي يلعب بعض التأثيرات المهمة جدًا أيضًا، خاصة في مجالات مثل محاذاة الذاكرة والحشو.

محاذاة الذاكرة والحشو

تتعلق محاذاة الذاكرة بكيفية وضع البيانات والوصول إليها من الذاكرة. عادةً، يمكن أن يكون لوحدة المعالجة المركزية (CPU) انحياز فيما يتعلق بمكان جلب البيانات في الذاكرة، وهو ما يشار إليه بحدود المحاذاة. على سبيل المثال، يجب وضع عدد صحيح 32 بت أو جلبه من عنوان البايت الرابع. في الحالات التي توجد فيها حقول في البنية الخاصة بك والتي لم تتم محاذاتها بشكل صحيح، عند النقر فوق الصفحات، قد يضيف مترجم Go بايتات الحشو، وما إلى ذلك. وهذا يصبح مضيعة للغاية. على سبيل المثال، انظر إلى هذه البنية.

struct example{

a bool   // 1 byte

b int32 // 4bytes;

c bool   // 1byte 

d int64 //8 bytes
}

في هذه البنية غير الصحيحة بسبب قواعد المحاذاة، قد يضيف مترجم Go واحدًا أو أكثر من بايت الحشو في منتصف هذه الحقول:

• a هو بايت واحد ولكن b يريد 4 بايت محاذاة ومن ثم يتم إدراج الحشو 3 بايت

• يبلغ طول b 4 بايت

• طول c هو 1 بايت ولكن لمحاذاة d التي تتطلب 8 بايت هناك 7asing ومن ثم يتم تقديم الحشو.

• طول d هو 8 بايت

كيف يكون الخشب خشبًا هيكليًا، لا يزال حجمه 24 بسبب الأرجل على الرغم من أن المحتوى يستغرق فقط 14 ولكن انظر إلى حجم المحتوى الفعلي بالإضافة إلى حجم الحشو .

إعادة ترتيب الحقول للحد الأدنى من الحشو

يمكن أن يساعد ترتيب الحقل وإيجاد البنية في تجنب إضاعة المساحة في شكل هامش سلبي. وبعبارة أخرى:

type Example struct { 

d int64 // 8 bytes

b int32 // 4 bytes

a bool // 1 byte

c bool // 1 byte

}

في الهيكل الأمثل أعلاه:

• د يشغل 8 بايت.

• b تشغل 4 بايت.

• a وc يشغلان بايت واحد لكل منهما دون الحاجة إلى الحشو.

يبلغ حجم هذه البنية الآن 16 بايت فقط وهذا أفضل من الهيكل السابق بحجم 24 بايت .

لماذا هذا مهم؟

عندما ينظر المرء إلى التطبيقات الصغيرة الحجم الشائعة، فمن المرجح أن يجد أن مقدار الذاكرة المستخدمة من قبل التطبيق لا يختلف عن الأخير. ومع ذلك، ليس هذا هو الحال في البناء حيث يكون الأداء وحتى مساحة الذاكرة أمرًا بالغ الأهمية، ضع في اعتبارك نظامًا مدمجًا، وتطبيقات تداول عالية التردد فائقة السرعة، أو التطبيقات التي تهدف إلى معالجة كميات هائلة من البيانات، يمكن لهذه القيود المخلصة أن تضيف ما يصل بسرعة. يصبح هذا أكثر وضوحًا عندما يتم إنشاء أو تشغيل العديد من المصفوفات الكبيرة أو شرائح الهياكل المتسلسلة. ليس من السهل ملاحظة التحيز أو اتحاد التحميل عندما تكون سعة البنية أكبر ببضعة بايتات فقط. عندما يتم إنتاج بنية الذاكرة المنخفضة بكميات كبيرة، مع كمية الملايين من الحالات التي يجب التعامل معها، شيئًا فشيئًا، لم تعد هذه الجرعة الزائدة من الهدر غير معروفة.

خاتمة

لا يعد ترتيب الحقول أمرًا رائعًا من وجهة نظر تصميم بنية Golang فحسب، بل يلعب أيضًا دورًا مهمًا في تحسين الذاكرة. إن فهم هذا الجانب من كيفية قيام Go بتخطيط الذاكرة للبنيات الخاصة بك ووحدات البكسل الخاصة بها يتيح تصميمًا أكثر فعالية للبنية في الممارسة العملية. يمكن أن يؤدي مثل هذا التعديل غير المهم إلى زيادة كبيرة في الأداء عندما يتعلق الأمر بالتطبيقات التي تستخدم الذاكرة بشكل مكثف. عندما تأتي الفرصة التالية لك لتحديد البنية في Go، لا تقم فقط بسكب تلك الحقول. بدلاً من ذلك، اقضي دقيقة واحدة في التفكير في التسلسل، وستكون ممتنًا لنفسك ولطلبك الذي قدمته في الأيام القادمة!