در این پست ، ما تأثیر تنظیمات مختلف حافظه حافظه را بر عملکرد یک پروژه معین تجزیه و تحلیل می کنیم. یک فرض متداول این است که افزایش تخصیص پشته حافظه باعث بهبود عملکرد ساخت می شود. با این حال ، در این مقاله ، معیارهای مختلفی را برای تعیین اثرات واقعی تنظیمات مختلف حافظه ارزیابی می کنیم.
راه اندازی آزمایش
تنظیم این آزمایش ساده است. دوندگان اقدامات رایگان GitHub حداکثر 16 گیگابایت حافظه را ارائه می دهند. روند ساخت ما ، که شامل دویدن است assembleDebug در nowinandroid، از دو مؤلفه اصلی تشکیل شده است:
- روند درجه یک
- فرآیند کامپایلر کوتلین
برای تجزیه و تحلیل تأثیر تخصیص حافظه ، چندین تنظیم را در محدوده 2.5 گیگابایت تا 7 گیگابایت تعریف می کنیم و در 1 گیگابایت افزایش می یابد. حداقل 2.5 گیگابایتی انتخاب شد زیرا یک تخصیص 2 گیگابایتی منجر به خطای پیش بینی شد.
تنظیمات آزمایش شده عبارتند از:
- 2.5 گیگابایت
- 3 گیگابایت
- 4 گیگابایت
- 5 گیگابایت
- 6 گیگابایت
- 7 گیگابایت
این مقادیر با استفاده از آرگومان های JVM زیر در gradle.properties تنظیم شده است:
org.gradle.jvmargs=-Xmx{$VARIANT}g -Xms{$VARIANT}g ...
kotlin.daemon.jvmargs=-Xmx{$VARIANT}g -Xms{$VARIANT}g ...
ما از همان پیکربندی Nowinandroid استفاده می کنیم ، کجا Xmx وت Xms مقادیر یکسان هستند و جمع کننده زباله G1 فعال است.
روش شناسی
هر پیکربندی 20 بار بر روی نمایندگان تمیز اجرا می شود ، با وابستگی هایی که در خانه کاربر Gradle از قبل بارگذاری شده است. هر تکرار یک اسکن ساخت ایجاد می کند که بعداً با استفاده از API Develocity مورد تجزیه و تحلیل قرار می گیرد.
نتایج
زمان ساخت
اولین متریک که ما ارزیابی می کنیم زمان ساخت کلی برای هر پیکربندی حافظه است.
یک مشاهده مهم این است که بین افزایش تخصیص پشته و کاهش زمان ساخت ، ارتباط مشخصی وجود ندارد. علاوه بر این ، انحراف استاندارد پایین نشان می دهد که زمان ساخت متوسط در تنظیمات مشابه است. در زیر تجزیه و تحلیل میانه زمان ساخت در هر پیکربندی وجود دارد:
حداکثر استفاده از حافظه
Develocity داده های استفاده از منابع را در اسکن های ساخت فراهم می کند ، ما حداکثر استفاده از حافظه فرآیند ساخت را تجزیه و تحلیل می کنیم. نتایج به خوبی با تنظیمات حافظه اختصاص یافته تراز می شود:
ما افزایش خطی در استفاده از حافظه تا 4 گیگابایت مشاهده می کنیم. با این حال ، برای تخصیص های بزرگتر ، واریانس افزایش می یابد ، نشان می دهد که فرآیند Gradle ممکن است در سناریوها با 6 گیگابایت یا 7 گیگابایت همگام شود.
استفاده از حافظه کامپلین
در مرحله بعد ، ما استفاده از حافظه را برای فرآیند کامپایلر Kotlin بررسی می کنیم:
داده های اینجا پراکنده تر است. ما تجزیه و تحلیل مفصلی از این واریانس انجام ندادیم. از این نقطه به بعد ، ما روی داده های فرآیند Gradle تمرکز می کنیم.
زمان جمع آوری زباله
اکنون ، ما زمان جمع آوری زباله Gradle (GC) را در تمام مشاهدات تجزیه و تحلیل می کنیم:
برای مقایسه واضح تر ، میانه GC را بررسی می کنیم:
تنظیمات با تخصیص 2.5 گیگابایتی و 3 گیگابایتی ، زمان GC را به طور قابل توجهی بالاتر نشان می دهد. تفاوت بین تنظیمات بزرگتر بسیار کوچکتر است.
رویدادهای مجموعه زباله
برای بینش های اضافی ، ما از افزونه GC Report استفاده می کنیم ، که اطلاعات مربوط به مجموعه زباله ها را در هنگام اجرای ساخت ثبت می کند. اولین متریک برای تجزیه و تحلیل تعداد جمع شده مجموعه ها است (به استثنای Concurrent Mark Cycle):
- انواع مختلفی با 2.5 گیگابایت و 3 گیگابایت تعداد قابل توجهی از رویدادهای GC را تجربه می کنند.
- با افزایش تخصیص حافظه ، تعداد مجموعه ها کاهش می یابد ، اما کاهش خطی نیست.
بعد ، ما تجزیه و تحلیل می کنیم Pause Young (Normal) (G1 Evacuation Pause) رویدادها این مکث ها هنگامی اتفاق می افتد که موضوعات برنامه متوقف می شوند در حالی که اشیاء در نسل جوان جمع آوری می شوند و به فضاهای بازمانده یا نسل قدیمی منتقل می شوند:
هنگام بررسی سایر عوامل ، مانند اشیاء فرومایه (عادی) ، مشاهده می کنیم که فقط نوع 2.5 گیگابایتی دارای این ورودی ها است که حالت حافظه کوتاه را برای این نوع نشان می دهد.
جالب تر اینکه ، ما تجزیه و تحلیل می کنیم Pause Young (Concurrent Start) (G1 Humongous Allocation) رویدادها اینها هنگامی اتفاق می افتد که JVM فشار GC نسل قدیمی را پیش بینی می کند و پیش از این یک چرخه همزمان را شروع می کند-نشانگر افزایش فشار حافظه:
در اینجا ، تنظیمات حافظه پایین مجموعه های بیشتری از این نوع را ایجاد می کند. با شروع از 5 گیگابایت ، تنظیمات ثبات بیشتری را نشان می دهد ، با این که مقدار متوسط در یک رویداد در هر تکرار تثبیت می شود.
سخنان پایانی
در این مقاله رفتار فرآیند Gradle تحت تنظیمات مختلف پشته مورد تجزیه و تحلیل قرار گرفته است. یافته های کلیدی عبارتند از:
-
افزایش تخصیص حافظه به طور قابل توجهی مدت زمان ساخت را در این پروژه بهبود نمی بخشد.
-
حداکثر استفاده از حافظه واریانس جزئی را در تخصیص بالاتر (6 گیگابایت و 7 گیگابایت) نشان می دهد.
-
تخصیص پشته بزرگتر باعث کاهش زمان GC می شود ، اما تفاوت آن قابل توجه نیست.
-
تعداد مجموعه های GC با تخصیص بالاتر کاهش می یابد و در حدود 5 گیگابایت تثبیت می شود.
-
G1 وقایع تخصیص فرومایه نشان می دهد که تنظیمات با 5 گیگابایت یا بیشتر بهتر بهینه سازی می شوند.
بر اساس این یافته ها ، محیط های CI باید تخصیص حافظه را برای بهینه سازی عملکرد و ضمن به حداقل رساندن مصرف منابع ، متعادل کنند. به نظر می رسد که یک تخصیص 4 گیگابایتی یا 5 گیگابایتی بهترین تجارت بین عملکرد ساخت و راندمان حافظه را ارائه می دهد.
ساختمان مبارک!
