Masalah debugging lambat di Visual Studio .NET

87

Dalam contoh Visual Studio saya, bahkan jika saya baru saja menulis satu baris pengembalian dalam aplikasi konsol C #, saya akan membutuhkan satu menit setelah menekan F5untuk mengeksekusi kode sebenarnya (maksud saya waktu yang diperlukan untuk berhenti pada pernyataan pengembalian tunggal setelah menekan F5- Saya mengatur breakpoint pada pernyataan kembali dalam mainfungsi). Apa yang salah? Apakah ada daftar periksa?

Saya menggunakan Visual Studio 2008 VSTS edition dan debugging di Windows Server 2003 x64.

— George2
sumber

2

Hanya untuk memastikan ... Berapa banyak memori yang tersedia untuk Anda saat mencoba menjalankan kode? VS adalah memori babi dari pengalaman saya ...

— RSolberg

1

Apa perangkat keras Anda? Visual Studio sangat membutuhkan disk dan CPU, jadi memiliki mesin dengan harga terjangkau akan kurang dalam performa.

— William Holroyd

1

Memiliki> 2-3 breakpoint bersyarat ditangani dengan buruk oleh VS ...

— Simon Buchan

Saya memiliki memori 4G dan tidak ada proses lain yang berjalan pada saat yang bersamaan. Saya baru saja me-restart mesin saya beberapa kali dan mengalami gejala yang sama. Saya tidak bertemu dengan masalah seperti itu seminggu sebelumnya. Ada ide lebih lanjut?

— George2

2

Semuanya terdaftar di Debug-> Windows-> Breakpoints (Ctrl-Alt-B). Tapi Anda akan tahu jika Anda membuat ...

— Simon Buchan

150

Anda mungkin perlu menghapus semua breakpoint Anda --- perhatikan bahwa Anda perlu mengklik tombol "Hapus semua breakpoint" (atau gunakan Ctrl+ Shift+ F9), BUKAN hanya menghapusnya satu per satu. Jika Visual Studio telah merusak pengaturan solusi Anda, yang terakhir tidak akan berfungsi. Anda mungkin perlu menambahkan breakpoint terlebih dahulu, agar ini berfungsi (pintar, eh?).

Jika yang terburuk menjadi yang terburuk, Anda mungkin perlu menghapus .suofile Anda dan membiarkan Visual Studio memulai yang baru dari awal. Perhatikan bahwa Anda akan kehilangan pengaturan konfigurasi solusi pribadi Anda, namun (hanya untuk solusi ini, bukan yang lain). Namun, Anda mungkin ingin memindahkan / mengganti nama file untuk sementara hingga Anda menentukan apakah ini masalahnya atau tidak; dengan cara itu, Anda selalu dapat memindahkannya kembali. Saya telah melihat beberapa sumber online merekomendasikan untuk menghapus (memindahkan / mengganti nama) .ncbfile juga.

— zweiterlinde
sumber

2

Hai, zweiterlinde. Saya menemukan kemacetan harus berurusan dengan jaringan. Ketika saya mencolokkan kabel jaringan, kinerjanya sangat baik dalam debugging. Apakah Anda punya ide tentang mengapa? dan bagaimana cara mengevaluasi lebih lanjut?

— George2

menghapus file .suo 14Mb berhasil untuk saya :) sekarang hanya 150Kb. masalah terjadi setelah meningkatkan dari VS2010 Pro ke Ultimate

— GreyCloud

+1. Terima kasih banyak, itu berhasil). VS 2010 saya membutuhkan waktu 2 menit untuk memulai proyek di workstation. Hah. Benar-benar bug ....

— Arsen Zahray

Saya juga menghapus file .suo, tetapi saya melakukannya saat Visual Studio sedang berjalan. Ketika saya me-restart Visual Studio itu melampirkan debugger sangat cepat lagi, dan sepertinya itu menyimpan sebagian besar pengaturan saya.

— macet

+1 Terima kasih banyak, sungguh. Jadi dalam kasus saya menghapus file suo bekerja dengan sempurna untuk saya.

— Dean Seo

26

Saya sudah pernah melihat ini sebelumnya. Coba hapus semua breakpoint Anda dan kemudian atur yang Anda inginkan. Pukul F5. Apakah sekarang lebih cepat?

Saya baru saja memperhatikan bahwa Anda menyebutkan menyiapkan fitur debugging sumber .NET. Coba nonaktifkan itu. Konektivitas jaringan Anda ke server sumber Microsoft mungkin lambat. Nonaktifkan juga konektivitas server simbol apa pun di menu Tools → Options → Debugging → Symbols .

Coba juga nonaktifkan "Aktifkan evaluasi properti dan panggilan fungsi implisit lainnya" di menu Alat → Opsi → Debugging → Umum .

— m-sharp
sumber

1

Di jendela break point saya, hanya ada satu di pernyataan kembalian dari fungsi Utama saya. Ada daftar periksa lainnya?

— George2

1

Menambahkan lebih banyak hal untuk dicoba. Semoga membantu.

— m-sharp

Saya telah menghapus satu-satunya break point pada pernyataan kembali fungsi Utama saya, tetapi masih sangat lambat untuk memulai aplikasi dan berhenti, membutuhkan waktu 1 menit atau lebih. Ada ide lebih lanjut?

— George2

Berikut ide lain untuk mengisolasi masalah Anda. Coba lepaskan kabel jaringan Anda, mulai ulang studio visual dan tekan F5 pada proyek Anda. Apakah itu mengubah sesuatu?

— m-sharp

1

Coba nonaktifkan itu, konektivitas jaringan Anda ke server sumber Microsoft mungkin lambat. Juga nonaktifkan konektivitas server simbol di Tools> Options> Debugging> Symbols - Ini berhasil untuk saya

— Yousuf Azad

19

Atau hapus file .suo Anda yang dapat ditemukan di sebelah file solusi (.sln) Anda. Ini memecahkan masalah yang saya alami dengan sesi debug yang membutuhkan waktu lama untuk memulai dan berhenti.

— jujur
sumber

1 untuk menghemat kewarasan saya (dan menyelamatkan saya dari pemasangan ulang VS2010). Terima kasih!

— Chuck Dee

Ini juga merupakan solusi yang direferensikan pada MSDN: social.msdn.microsoft.com/Forums/vstudio/en-US/…

— ecoe

Mengonfirmasi hal ini juga berlaku untuk versi 2003.NET dan 2005 yang lebih lama. Satu aplikasi memiliki beberapa titik putus dan berjalan dengan baik. Menambahkan beberapa breakpoint lagi ... 100% penggunaan CPU dan kedipan yang mengerikan di VS saat debugging. Ditutup VS, dihapus .suo, dibuka kembali dan debugging cepat lagi.

— AlainD

Ini adalah solusi yang saya temukan selalu berfungsi setiap kali VS menjadi terlalu lambat dalam hal debugging

— Graviton

Atau ganti nama file .suo terlebih dahulu sebelum menghapus sehingga memungkinkan untuk kembali ke keadaan sebelumnya.

— Peter Mortensen

12

Saya punya masalah ini. Setelah mencoba semua saran yang terdaftar dan menghapus semua ekstensi Visual Studio, kami akhirnya menemukan bahwa entah bagaimana IntelliTrace telah diaktifkan. Menonaktifkan itu memperbaiki semuanya.

Cara: Mengaktifkan dan Menonaktifkan IntelliTrace

— Kevin DiTraglia
sumber

Ini juga menyelesaikan masalah jika Anda memiliki proyek yang menggunakan SharpDX - ini berfungsi untuk saya dan sekarang kinerja grafis kembali normal.

— komorra

Dalam kasus khusus menggunakan SharpDX dan Debug-Build, saya memiliki efek yang sama, tetapi hanya DX debugging yang diaktifkan. Jika tidak diperlukan, cari "DeviceCreationFlags.Debug" dan nonaktifkan

— thewhiteambit

Di VS2015 saya tidak mencentang 'Enable Intellitrace' dan mengklik OK. Belakangan diketahui bahwa Anda harus mengubah dari 'Intellitrace and call information' menjadi 'Intelllitrace events saja'; jika tidak, 'Aktifkan Intellitrace' TINGGAL DIPERIKSA!

— smirkingman

Memecahkan masalah! (jangan percaya pada komentar MS: "Topik ini hanya berlaku untuk Visual Studio 2010 Ultimate."). Saya memiliki edisi gratis 2017 dan mempercepat proses debug secara dramatis!

— marsh-wiggle

IntelliTrace di VS 2017 dan yang lebih baru adalah fitur khusus Perusahaan, jadi ini tidak memperbaiki masalah saya (karena saya hanya memiliki edisi VS 2017 Pro).

— FoxDeploy

6

Apakah Anda memiliki banyak set breakpoint? Itu benar-benar dapat memperlambat waktu startup. Setiap modul baru dimuat ke dalam ruang alamat proses, mereka semua perlu diperiksa untuk melihat apakah mereka valid.

— 1800 INFORMASI
sumber

Saya hanya memiliki satu titik istirahat dalam kode mode pengguna saya. Tapi saya ingat seminggu sebelum saya menggunakan fitur debugging sumber di Visual Studio untuk menetapkan beberapa titik istirahat ke kode internal .Net. Adakah cara untuk memeriksa semua break point termasuk. Net internal yang saya tetapkan?

— George2

Tidak ada, tapi masih lambat, ada ide lebih lanjut?

— George2

tidak juga, sepertinya perangkat keras Anda akan baik-baik saja dan semua item lain yang akan saya coba tampaknya telah dicentang oleh pemberi komentar lain. Pada titik ini saya mungkin akan mencoba memasang ulang studio visual - mungkin ada yang salah dengan pemasangannya

— 1800 INFORMATION

Saya menginstal ulang ke direktori lain tetapi masih mengalami gejala yang sama. Ada ide lebih lanjut?

— George2

6

Buka menu Tools → Options → Debugger → Symbols dan periksa apakah Anda memiliki set simbol publik atau set jalur jaringan UNC . Juga periksa menu Tools * → Options → Debugger → General untuk melihat apakah Anda telah menyetel server sumber.

Semua ini dapat memengaruhi debugging berdasarkan kecepatan jaringan yang lambat atau server yang tidak tersedia. Waktu tunggu 5 menit adalah waktu tunggu jaringan.

Jika tidak ada dalam opsi yang disetel, periksa untuk melihat apakah Anda telah menyetel variabel lingkungan _NT_SYMBOL_PATH.

— Steve Steiner
sumber

Terima kasih, ini untukku. Saya sesekali memuat 1 atau 2 file simbol di jendela Modules, menunjuk ke simbol dari build kami melalui jalur UNC, atau lebih jarang, menunjuk ke mesin virtual yang sudah tidak ada lagi. Tidak menyadari itu menyimpan semua jalur ini di pengaturan Debugger / Simbol.

— Brian

6

Rekan saya memiliki Visual Studio yang merespons dengan sangat lambat, dan benar-benar butuh beberapa menit untuk melakukan langkah saat debugging.

Akar penyebabnya ternyata adalah program anti virus (Threatfire) yang menjadi gila saat Visual Studio berjalan. Membunuh prosesnya segera memperbaiki semuanya.

— mafu
sumber

Saya memiliki pengalaman debugging web yang mengerikan di tempat kerja sampai saya menonaktifkan anti virus ESET. Setelah menekan F5, waktu respons saya berubah dari 2-3 menit menjadi 2-3 detik.

— James Hulse

1

Menangguhkan ThreatFire untuk sementara banyak membantu saya juga - terima kasih! (Mematikan Avast untuk sementara! Sedikit membantu juga, tapi tidak terlalu banyak.)

— Jon Coombs

Malwarebytes adalah penyebab masalah saya. Menghentikannya memperbaiki kelambatan.

— Ben Rubin

Saya juga menggunakan Malwarebytes ... Setelah berhenti, debugging VisualStudio jauh lebih cepat. Debug startup adalah 15 detik sebelumnya, sekarang menjadi 2 detik) .. Terima kasih!

— BlueDev

5

Dalam kasus saya, mengubah simbol debug "Secara otomatis memuat simbol untuk" opsi dari "Semua modul" menjadi "Hanya modul yang ditentukan" memecahkan masalah. Anda dapat mengubah opsi ini dari menu Tools → Options → Debugging → Symbols .

— cahit beyaz
sumber

3

Penyebab yang berbeda plus ... Bagaimana menemukan masalahnya

Bagi saya itu adalah opsi ShowOtherThreadIpMarkers . Nilai 1 membuat Visual Studio (2010) sangat lambat (3-5 detik untuk setiap langkah debug. Dengan nilai 0, itu cepat lagi.

Apa pilihan itu? Saya tidak punya ide. Saya tidak dapat menemukannya melalui antarmuka pengguna Visual Studio. Saya tidak mencentang semua opsi debugging yang mungkin di sana dan tidak ada yang berhasil.

Jadi saya pergi ke Pengaturan Impor / Ekspor dan memuat pengaturan lama saya yang sebelumnya saya simpan mundur dalam waktu sampai Visual Studio cepat lagi, kemudian membandingkan file vssettings ..., dll, dll.

Saya ingin mengomentari bahwa jika Anda memuat pengaturan saat Anda berada dalam mode debug berhenti pada breakpoint, pengaturan tersebut menjadi efektif segera. Anda tidak perlu menghentikan debugger dan memulai ulang.

— marcelloptr.dll
sumber

+1 Terima kasih, ini juga masalah saya dengan aplikasi web C # di VS2015. Saya menonaktifkan opsi "Show Threads in Source" di toolbar saat debugging dan masalahnya hilang. Jika opsi tidak tersedia di bilah alat, itu dapat ditemukan dengan mengklik kanan utas mana pun di dalam jendela Utas.

— Groo

2

Dari blog ScottGu yang ditautkan oleh Travis: "Satu lagi performa gotcha yang saya dengar baru-baru ini adalah masalah yang dilaporkan beberapa orang dengan add-in Google Toolbar. Untuk beberapa alasan, hal ini terkadang dapat menyebabkan penundaan yang lama saat memasang Visual Studio debugger ke browser. Jika Anda melihat penundaan yang lama dengan pemuatan aplikasi web Anda, dan Google Toolbar (atau toolbar lain) sudah terpasang, Anda mungkin ingin mencoba mencopot pemasangannya untuk melihat apakah itu penyebab masalah. "

— Kucing Zimmermann
sumber

Apakah Anda sudah menginstal Google Toolbar? Bahkan mengatakan tidak akan membantu pembaca pertanyaan ini di masa mendatang.

— Cat Zimmermann

Saya membuka IE dan tidak ada toolbar yang ditampilkan, apakah itu berarti saya tidak menginstal toolbar dan tidak akan mempengaruhi Visual Studio? :-)

— George2

2

Wow. Saya pikir itu tidak masuk akal, tetapi saya baru saja mencopot pemasangan dan mesin saya kembali ke mode yang dapat digunakan

— orellabac

1

Plugin lain yang disalahkan adalah LastPass. Apakah ini hanya masalah dengan IE atau apakah plugin di browser apa pun dapat memengaruhi banyak hal?

— Denise Skidmore

1

@DeniseSkidmore Anda luar biasa, saya berharap saya dapat meningkatkan suara lebih dari sekali. Semua solusi lain ini dan tidak ada yang membantu ... lalu saya membaca komentar Anda, menonaktifkan add-in LastPass IE dan tiba-tiba menjadi cepat lagi. Saya mengonfirmasi bahwa ini adalah masalahnya dengan mengaktifkan kembali add-in dan itu melambat kembali. TERIMA KASIH!!!!

— Lews Therin

2

Berjalan di bawah debugger bagi saya kira-kira 10x lebih lambat daripada berjalan tanpa debugging.

Setelah mencoba setiap solusi yang disarankan di sini, saya memeriksa setiap pengaturan debugger dan diaktifkan / dinonaktifkan untuk melihat apakah ada perbedaan.

Bagi saya, ternyata menonaktifkan pengoptimalan Suppress JIT pada pemuatan modul di pengaturan debug secara besar-besaran meningkatkan banyak hal.

— Ben Hughes
sumber

1

Pastikan Anda tidak memiliki pemetaan jaringan lama ke server yang sudah tidak ada (waktu tunggu jaringan akan mematikan Anda). Atau gunakan sesuatu seperti Process Monitor untuk melihat apakah jaringan (atau kesalahan file lainnya) tampaknya memblokir untuk waktu yang lama.

— Michael Burr
sumber

Process Monitor adalah alat yang keren! :-) Tetapi opsi mana dalam Monitor Proses yang dapat digunakan untuk melihat "jika jaringan (atau kesalahan file lainnya) tampaknya memblokir untuk waktu yang lama"?

— George2

Saya akan mencari hal-hal seperti kesalahan ketika mencoba membuka file atau berapa lama operasi berlangsung (jangan lupa ada item data yang mungkin tidak Anda lihat seperti 'Durasi' yang dapat Anda pilih di Opsi / Pilih Kolom ...) . Gunakan filter dan sorotan untuk keuntungan Anda.

— Michael Burr

Hai Michael Burr, dalam Monitor Proses yang Anda maksud adalah memantau proses VSTS itu sendiri atau memantau semua proses di mesin?

— George2

Saya pasti akan mulai hanya dengan VSTS (devenv.exe) atau Anda akan dibanjiri dengan informasi yang hampir pasti tidak berguna.

— Michael Burr

1

Anda akan ingin menggunakan "Process Monitor" bukan "Process Explorer". Lihat technet.microsoft.com/en-us/sysinternals/bb896645.aspx . Kedua utilitas tersebut memiliki fungsi yang berbeda. Procmon akan melacak operasi file dan registri. Procexp adalah utilitas praktis tetapi tidak menyediakan jenis penelusuran itu.

— Michael Burr

1

Apakah Anda menggunakan SymbolServer untuk mengunduh simbol untuk file DLL Windows?

Jika demikian, nonaktifkan itu karena bisa memakan waktu, tetapi saya tidak berharap itu menyebabkan penundaan lama dalam aplikasi konsol dasar.

Alat Menu → Pilihan → Debugging → Simbol .

— Michael Prewecki
sumber

Konten kosong di Tools> Options> Debugging> Symbols. Ada ide lebih lanjut?

— George2

1

Saya tahu ini adalah topik lama, tetapi untuk apa nilainya ...

Saya telah menemukan bahwa jika saya membuka jendela Internet Explorer terpisah untuk waktu yang lama, diperlukan waktu hingga satu menit untuk memulai debugging. Tutup semua jendela Internet Explorer dan debugging akan segera dimulai.

— Robbie
sumber

1

Dalam kasus saya, Google Toolbar memperlambat proses debug saya.

gplus_notifications_gadget.html terus berjalan dan membebani debugger secara berlebihan. Saya ingin mempertahankan Google Toolbar karena saya menggunakannya secara teratur, jadi saya hanya menonaktifkan tombol notifikasi G + (tombol kecil di samping tombol profil). Bahagia sekarang.

— wcloister
sumber

1

Saya memiliki masalah yang sama di Visual Studio 2010, dengan menginjak kode sangat lambat (antara 3 hingga 10 detik). Namun, tidak ada modifikasi pengaturan di atas yang berhasil.

Saya akhirnya menemukan solusi pamungkas, yang akan berfungsi di semua masalah posting di atas: setel ulang semua pengaturan Anda, seperti yang dijelaskan di sini (pada dasarnya menu Alat → Pengaturan Impor dan Ekspor , Setel ulang semua pengaturan , dengan menyimpan pengaturan yang ada ke file (untuk mengembalikan )).

Anda mungkin ingin menyimpan bagian tertentu dari pengaturan Anda terlebih dahulu. Misalnya, saya pertama kali menyimpan tema warna saya (seperti Solarized) dan kemudian mengembalikannya setelah reset global.

— Spikegee
sumber

1

Bagi saya, pengaturan yang mematikan kinerja (Windows 8 bahkan macet kecuali untuk gerakan mouse) adalah untuk menghapus centang "Hentikan semua proses ketika satu proses rusak" di menu Pilihan → Debugging → Umum .

— Niels
sumber

1

Hanya satu lagi penyebab pengalaman debugging Visual Studio yang lambat ...

Dahulu kala saya mengaktifkan FusionLoguntuk melihat apa yang menyebabkan masalah pengikatan perakitan.

Pastikan Anda menonaktifkannya setelah menggunakannya. Mengapa? Karena itu menulis banyak data logging ke disk saat diaktifkan.

Ini adalah FusionLogkunci di Window's Registry ( regedit.exe):

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion

Ubah ForceLog, LogImmersivedan LogResourseBindingsnilai dari 1 (aktif) menjadi 0 (nonaktif).

— Leniel Maccaferri
sumber

Itulah yang terjadi pada saya. Anda juga dapat menonaktifkan Fusion Log melalui gui-nya: hanselman.com/blog/…

— Denise Skidmore

Anda dapat melihat apakah ini masalah Anda saat menjalankan Process Monitor, Anda akan melihat semua akses ke file Fusion Log.

— Denise Skidmore

0

Saya juga mengalami masalah ini, tetapi tidak ada hubungannya dengan breakpoint dalam kasus saya. Itu adalah pintasan kode yang saya tambahkan di jendela tugas:

http://www.customsoftwareframeworks.com/blog/longwaittimetoinsertoraddalineoftextbuginvisualstudio--tasklistwindow--onlywhenaddingandremovelines

Saya yakin ada cara lain untuk melihat masalah seperti ini, tetapi ada bug di suatu tempat yang menyebabkan masalah ini bagi saya ... menghapus semua opsi saya akan memperbaiki masalah ini, tetapi itu adalah sesuatu yang tidak saya inginkan. melakukan. Jadi, saya men-debugnya dan menulis tentang itu di blog saya ... masalah Anda terdengar seperti milik saya.

— shawn
sumber

Tautan rusak: "Sumber daya yang Anda cari telah dihapus, namanya diubah, atau untuk sementara tidak tersedia."

— Peter Mortensen

0

Sesuatu yang berhasil bagi saya adalah memastikan tidak ada break point bersyarat. Selain itu, saya telah berhasil memperbaiki debugging yang lambat hanya dengan memulai ulang Visual Studio dan hanya membuka satu contoh Visual Studio pada satu waktu.

— jjxtra.dll
sumber

0

Saya memiliki masalah serupa dan tidak ada panduan lain yang tampaknya membantu. Saya telah reboot tetapi tidak berhasil. Saya telah menghapus semua breakpoint, menghapus file .suo, memeriksa bahwa simbol tidak dimuat dari sumber eksternal, dan memeriksa bahwa tidak ada jalur di aplikasi yang tidak tersedia.

Lalu, saya berpikir untuk membersihkan solusinya. Saya melihat di jendela keluaran bahwa C # IntelliSense melaporkan masalah saat membersihkan:

Ada masalah saat membaca metadata dari '{B0C3592F-F0D1-4B79-BE20-3AD610B07C23}' ('Sistem tidak dapat menemukan file yang ditentukan.'). IntelliSense mungkin tidak berfungsi dengan benar hingga solusi dimuat ulang.

Dalam kasus ini, setelah Anda benar-benar menemukan pesan kesalahan, itu memberi tahu Anda cara mengatasinya. (Kerja bagus pada teks kesalahan, pekerjaan buruk pada kemudahan ditemukan!) Saya membongkar proyek solusi, lalu memuatnya kembali. Saya kemudian berhasil menjalankan solusi bersih . Itu berhasil, dan debugger juga melakukannya.

— Mike L.
sumber

0

Menutup jendela "Autos" meningkatkan debugging untuk saya di Visual Studio 2008 untuk solusi C ++ asli yang besar.

Menyembunyikannya tidak akan berhasil. Itu harus ditutup.

— javs
sumber

0

Saya mengalami perlambatan yang sama dan memutuskan sambungan dari jaringan memperbaiki masalah bagi saya seperti yang dinyatakan oleh beberapa komentar dan jawaban lain (tetapi tentu saja itu bukan perbaikan yang ideal).

Untuk kasus saya, perubahan sederhana ini memperbaiki solusi saya: Di properti proyek pada tab debug saya menonaktifkan "Mengaktifkan proses hosting Visual Studio" (Saya menjalankan Visual Studio 2010).

— menggabungkan
sumber

-9

Dapatkan lebih banyak memori dan HD yang lebih cepat. Detail selengkapnya ada di sini .

— tsimon
sumber

1

Saya rasa ini bukan masalah H / W, karena perangkat keras saya adalah memori 4G + 2 CPU (2.33G), apakah itu cukup? BTW: Saya tidak mengalami ini seminggu sebelumnya, jadi saya pikir ini harus menjadi masalah konfigurasi?

— George2

2

+1 Saran yang berguna, tidak percaya orang-orang memilih ini. Meskipun menghapus file .suo Anda membantu 10x lebih banyak.

— Andomar

1

OP bahkan belum memberi tahu apa spesifikasi mereka. Jika Anda menasihati saya, Anda akan menasihati saya untuk mendapatkan lebih dari 32 Gb Ram dan lebih cepat dari solid state saya yang sudah cepat.

— Valamas