(Sumber: milist DOTNET) Application Startup Time Improvement dengan Multi-core JIT di .NET 4.5 (Beta)
-
30 April 2012 7:40Moderator
Kemarin saya nanya2 tentang cara meningkatkan kinerja waktu startup aplikasi dengan multi-core JIT di .NET 4.5 Beta. Jadi ini ceritanya ada fitur baru di .NET 4.5. Diskusinya ada di sini: http://social.msdn.microsoft.com/Forums/en-US/clr/thread/0ca52427-f45f-489d-9d4b-c52be6edc0af/. Infonya juga ada di sini: http://msdn.microsoft.com/en-us/magazine/hh882452.aspx dan http://blogs.msdn.com/b/dotnet/archive/2012/03/20/improving-launch-performance-for-your-desktop-applications.aspx.
Saya sendiri itu udah nyoba meng-enable multi-core JIT pake ProfileOptimization (http://msdn.microsoft.com/en-us/library/system.runtime.profileoptimization(v=VS.110).aspx) di sebuah WPF app. Dari hasil measurement, lumayan ada peningkatan application startup time sekitar 8-10%. Mungkin bisa lebih baik peningkatannya, tergantung skenario dari aplikasi itu sendiri. Fitur ini juga lebih ditujukan untuk desktop app daripada web app.
Ada juga fitur lainnya yang namanya MPGO (Managed Profile Guided Optimization). Cuma saya belum bisa nyoba, pas nyoba dapet error yang belum resolved soalnya.
Mudah2an berguna buat rekan2 yang lain.
Agnes Sannie [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Semua Balasan
-
30 April 2012 7:41Moderator
kebanyakkan pass coba mpgo, handle path-nya masih belum bagus. jadi kita bantu dengan full-path.
mungkin gambar di bawah bisa di coba.
Dijawab oleh: dede
Agnes Sannie [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help. -
30 April 2012 7:43Moderator
Iya, bener, masih belum bagus path handling-nya. Saya udah coba pake full path, juga tetep ga bisa. Masalah saya itu keliatannya di argument AssemblyList. Kalo di contohnya 'kan bisa pake wild cards "*.*". Ternyata pas dicoba ga bisa, mesti di-provide explicitly. Kalo dependency satu, ga masalah. Kalo banyak, jadi repot... :D
Agnes Sannie [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help. -
30 April 2012 7:43Moderator
katanya namanya BETA... :)
Kalau dependency-nya banyak, kita bisa buat helper yang baca assembly-nya lalu membuat list AssemblyList argument-nya.
seperti code di bawah, itupun kalau masih penasaran sama mpgo ini. :)
http://dl.dropbox.com/u/19973434/NetIndonesia/Codes/MPGO/MPGOHelper.cs
Dijawab oleh: dede
Agnes Sannie [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.- Ditandai sebagai Jawaban oleh Agnes SannieMicrosoft Contingent Staff, Moderator 30 April 2012 7:51
-
30 April 2012 7:46Moderator
He...3x, memang bener sih masih beta, cuma ga nyangka bakal kayak gitu juga. Lagian saya juga cuma ngikutin contoh yang dikasih... :D
Anyway, thank bos untuk helpernya. Saya ga kepikiran bisa dibikin helper/wrapper kayak begitu. Saya coba dulu kalo begitu.
Agnes Sannie [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help. -
30 April 2012 7:49Moderator
BTW, mantep bos helper-nya. Saya suka liat code-nya, bener2 OO. Even untuk setting foreground color Console pun sampe pake IDisposable... he...3x. Tapi saya setuju, memang harus begitu sih biar rapi kodenya.
Saya juga suka dengan implementasi MPGOAssemblyListBuilder(string) di bagian ini:
allAssemblies.AddRange(
@"*.dll|*.exe"
.Split('|')
.SelectMany(filter => Directory.GetFiles(assemblyWorkingPath, filter))
.Select(Assembly.LoadFile)
.Where(
workingPathAssembly =>
assemblyTarget.GetReferencedAssemblies().Any(
referenceAssembly =>
referenceAssembly.FullName.Equals(workingPathAssembly.FullName))));Bener2 clean, simple, dan elegant... :D Tapi saya ubah dikit memang di bagian Where()-nya menjadi begini:
allAssemblies.AddRange(
@"*.dll|*.exe"
.Split('|')
.SelectMany(filter => Directory.GetFiles(assemblyWorkingPath, filter))
.Select(Assembly.LoadFile)
.Where(
workingPathAssembly =>
!assemblyTarget.FullName.Equals(workingPathAssembly.FullName)
&& !workingPathAssembly.Location.ToUpper().EndsWith("VSHOST.EXE")));karena setelah saya coba, GetReferencedAssemblies() ga me-refer ke semua assembly yang sebenernya dibutuhin assemblyTarget waktu runtime, mungkin karena faktor runtime loading. Jadinya biar gampang, ya saya include aja semua assembly keluaran dari VS/MSBuild.
Setelah sukses di-profile pake MPGO dan di-measure, peningkatan application startup time pake MPGO memang jauh lebih signifikan dibandingin pake Multicore JIT. Sebagai perbandingan, kalo pake Multicore JIT bisa diperoleh peningkatannya sekitar 10%, sedangkan kalo pake MPGO menjadi sekitar 20%! Signifikan bener nilainya. Mungkin juga memang karena faktor NGen juga yang me-native-kan assembly2 yang dipake.
So, thanks, bos sekali lagi untuk helper-nya. It's very helpful... :D
Dijawab oleh: dede
Agnes Sannie [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.