VPN paylaşımında yavaş Visual Studio: yadda saxlama niyə gediş-dönüşlərə çevrilir

Yerli diskdən bir saniyədə açılan həll tunel ilə çatılan paylaşımdan otuz saniyəyə açılır. Tunel nadir hallarda təkbaşına səbəbdir. Dəyişən odur ki, əvvəl yerli çağırış olan əməliyyatlar sinxron gediş-dönüşlərə çevrilir, və redaktor pəncərə görünməzdən əvvəl onlardan bir neçəsini yerinə yetirir. Aşağıdakı mexanizm hər birinin niyə baha olduğunu və hansılarını silə biləcəyinizi izah edir.

Fayl açıqken redaktor nə edir

Dəyişiklik izləməsi olan redaktor açdığı hər fayl üzərində abunə saxlayır. Yerli həcm bu abunəni şəbəkəsiz, fayl sistemindən təmin edir. Paylaşım üzərində eyni xüsusiyyət təkrar metadata oxumalarına çevrilə bilər, çünki bildiriş modeli SMB üzərində eyni cür işləmir. Dəyişiklik izləməsini söndürmək ədalətli ilk təcrübədir, çünki tunelə toxunmadan bütöv bir sorğu sinfini aradan qaldırır.

Layihə sistemi öz trafikini əlavə edir. Həlli yükləmək qovluqları siyahıya alır, layihə fayllarını oxuyur və SDK-ları və ya paketləri yoxlaya bilər, yol uzaq olduqda isə hər yoxlama bir gediş-dönüşdür. Çox layihəli həll bu sayı çoxaldır, buna görə açılma vaxtı fayl ölçülərinin təklif etdiyindən daha sürətli artır.

Menyu görünməzdən əvvəl vaxtı bitən qabıq axtarışları

Windows IDE ilə heç bir əlaqəsi olmayan ikinci dayanma mənbəyi verir. Explorer və onun qabıq uzantıları əvvəl istifadə edilmiş printerləri, qoşulmuş diskləri və qısayolları hər dəfə kontekst menyusu açılanda yenidən həll edir. Bu hədəflər tunelin çata bilmədiyi şəbəkədə olduqda, hər həll vaxt bitənə qədər bloklanır və yalnız bundan sonra menyu çəkilir. Buna görə fayl özü normal açılarkən sağ klik saniyələrlə dona bilər.

Ölü bağlamaları və printer növbələrini silin, ya da yalnız həqiqətən olduğunuz şəbəkədə mövcud olanları saxlayın. Eyni məntiq arxa planda yol həll edən hər şeyə, o cümlədən son fayllar siyahısına və bərkidilmiş qovluqlara aiddir.

net use
Get-Printer | Select-Object Name, PortName
Measure-Command { Get-ChildItem \files\proj | Out-Null }

Niyə yerli iş nüsxəsi qalib gəlir

Paylaşım üzərində birbaşa işləmək redaktə-qurma-test dövrü üçün ən pis quruluşdur, çünki redaktor, kompilyator və versiya nəzarəti müştərisi həmin uzaq faylları ayrı-ayrılıqda oxuyur. Onların hər biri öz gediş-dönüşünü ödəyir, qurma isə hər fayl üçün bir dəfə ödəyir. Repozitoriya vasitəsilə push edilən yerli nüsxə çoxsaylı kiçik keçidləri bir məqsədli keçidlə əvəz edir. Əlaqə yaxşılaşmadı; keçidlərin sayı çökdü.

Bu, tənzimləmə məşqi deyil, struktur dəyişikliyidir və tunel parametrləri işləməyəndə məhz buna görə işləyir. O, həm də uğursuzluq modelini aydın edir: yerli nüsxə ilə qurma hələ də yavaşdırsa, paylaşım heç vaxt problem deyildi.

Tarixçəni bir obyekt kimi köçürün

Repozitoriyanın özü tuneldən keçməlidirsə, tarixçəni gəzmək əvəzinə bir obyektdə göndərin. Paket bir fayl və buna görə bir ötürmədir, halbuki minlərlə sərbəst obyekti gəzən checkout minlərlə keçidə başa gəlir. Mercurial və Git bu formanı dəstəkləyir.

hg bundle --base 9f2c1a7e outgoing.hg
hg unbundle outgoing.hg
git bundle create repo.bundle main
git clone repo.bundle repo

Baza revizyonu düzgün qurulmalı hissədir, çünki nə qədər tarixçənin səyahət edəcəyini o müəyyən edir. Hər şeyi paketləmək işləyir və əlaqəni israf edir, sonuncu ortaq dəyişiklikdən paketləmək isə yalnız qarşı tərəfin çatışmayanını köçürür.

Kanal enini günahlandırmadan əvvəl üç əməliyyatı ölçün

Üç şeyi ayrı-ayrı ölçün: bir kiçik fayl açıldı, bir qovluq siyahıya alındı, bir saxlama tamamlandı. Əgər üçü də fayl sayına uyğun olaraq yavaşdırsa, xərc gediş-dönüşlərdir. Biri dayanıb digərləri yaxşıdırsa, kanal eni deyil, əlçatmaz resursa qarşı vaxt aşımından şübhələnin. Hər ölçmədə maşının hansı şəbəkədə olduğunu qeyd edin, çünki başqa profilə yenidən qoşulan noutbuk cəhdlər arasında cavabı dəyişə bilər.

Sonra eyni üçü layihənin yerli nüsxəsinə qarşı təkrarlayın. Fərq paylaşımın qiymətidir və kimsə düzəliş kimi daha sürətli əlaqə təklif edəndə sitat gətiriləcək rəqəm budur.