Czemu git śmiga na macu 100x szybciej niż na Windowsie?

2

Zauważyłem taką zależność. Jak robię commity, albo pracuję z interactive rebase (git rebase -i), nie ważne czy z command line'a czy z GUI z IntelliJ'a, na macu po prostu klikam "Ok" i jest (albo klikam "Enter") i jest. To nawet nie jest 0.5 czy 0.25 sekund. Jak klikniecie myszką.

Ale jak pracuję w domu, na prywatnym kompie na windowsie, to commity już nie są takie szybkie, a git rebase -i wydaje mi się jakby był tym dłuższy im więcej commitów rebase'uję ;o

Nie mam takiego słabego kompa ten windows, np ssd mam 3500Mb/s, procesor i7'ka 7dmej generacji HQ, niedawno wymieniłem kości RAM z 10tki na 7ki (opóźnienia) Więc nie wiem z czego to może wynikać ;|

Czyżby sam git.exe był tak super wolniejszy niż unixowy odpowiednik?

0

Może jakieś problemy z siecią?
Kiedyś na Windows była znacząca różnica w wydajności pomiędzy 127.0.0.1 a localhost.

4

Raczej nie problemy z siecią, bo lokalny rebase tez dlugo trwa.

A co do tematu. Ile tych commitów czy rebasów robisz dziennie żeby to mialo mieć znaczenie? Czy po prostu chcialeś nam oznajmić jaki to Mac jest fajny?

4

Moze masz antywirusa ? :)

4

Windows Defender skanujący katalogi z repo?

1

Podobny przypadek: mam na dual boocie Windowsa 10 i Minta 19. Na Linuxie KeePass otwiera bazę w ok. 2 sekundy, a na Windowsie w kilkadziesiąt (ta sama baza, wyłączony AV).

0

@Potat0x: w zakresie zestawienia Win10 i Mint19 - mam taki sam zestaw, dual boot na laptopie. Bardzo wyraźnie widać różnice w prędkości działania AndroidStudio, odpalania emulatora i ogólnym komforcie użytkowania.

2

To jeszcze może być coś ze sterownikami np. karty graficznej. Zasadniczo jednak Git był pisany na Linuxie i systemy tego typu lepiej sobie radzą z systemami plików i operacjami na nich. NTFS jest już dość stary w porównaniu do coraz nowszych ext. Git trzyma historię w plikach - w dużej ilości, więc jest to na korzyść Linuxów i Maka.

Swoją drogą - Ty piszesz w PHP to czemu pracujesz prywatnie na Windowsie? Ja pracuję z domu na Ubuntu, a mam Win 10 tylko do gier ;)

8

Git jest stworzony i zoptymalizowany dla linuksa/uniksa, bazuje na wielu małych pliczkach i wykonuje operacje stat wiele razy które są błyskawiczne na linux/unix ale niestety bardzo wolne na windowsie

Microsoft stworzył z tego powodu własny wirtualny system plików dla gita żeby przyspieszyć działanie gita w swoich własnych projektach - możesz wypróbować
https://vfsforgit.org/
https://github.com/microsoft/VFSForGit

Osobiście nie testowałem, ale wygląda obiecująco jeśli performance naprawdę Ci doskwiera - u mnie w firmie git jest mega wolny ale to nie wina windowsa tylko serwera bo to na operacjach serwerowych jest w moim przypadku stracona większość czasu. Brałem pod uwagę postawienie lokalnego klona repozytorium działającego jako proxy - są takie rozwiązania gotowe ale i tak wymagają sporo konfiguracji więc pewnie trochę jeszcze upłynie czasu zanim się podejmę próby

2

Coś jest na rzeczy
U mnie odpalone na tej samej maszynie
git 2.17.1
time git status
odpalone na folderze z ghc (to gruby projekt)

ubuntu na windows (wls)

real    0m2.414s
user    0m0.078s
sys     0m4.672s

Folder wyłączony w defenderze - innych antywirusów nie mam.

linux (pod vmware)

real	0m0.121s
user	0m0.076s
sys	0m0.085s

Może dlatego nawet nie przychodzi do głowy mi developowanie na windows.
Czasem sprawdzam tylko pod windows jak to jest z tym write once run anywhere ...

EDIT:
Nudziło mi się - i po 15tu restartach, kilku unistallach (1.5 godziny życia w plecy) - zadziałało wsl2

real    0m0.192s
user    0m0.046s
sys     0m0.067s

Czyli czasy porównywalne z ubuntu pod vmware. Coś tam jednak się zmienia.

8

To teraz już wiemy czemu cała zawartość https://github.com/dotnet/coreclr/blob/master/src/gc/gc.cpp jest w jednym pliku - po to, żeby dało się to na Windowsie wersjonować :P

0

Podsumowując dyskusje - windows ma zj****y system plików i dopóki go nie zmienia nie nadaje sie do programowania.

A na powaznie to pamiętam że 10 lat temu system plików na windowsie był tak duzym problemem dla gita że ostatecznie w projekcie studenckim użyliśmy mercuriala (mielismy jednego odszczepienca co nie chciał pracować na linuksie)

0

Może to kwestia włączonej w Windows usługi indeksowania zawartości plików? Można prosto zweryfikować, przez wykluczenie katalogu repozytorium z zakresu indeksowania...

1

Poszperałem na SO: https://stackoverflow.com/questions/42888024/git-bash-mintty-is-extremely-slow-on-windows-10-os - przyznam, że niektóre, rzekomo działające porady, kładą mnie na łopatki.

3
Pipes napisał(a):

Swoją drogą - Ty piszesz w PHP to czemu pracujesz prywatnie na Windowsie? Ja pracuję z domu na Ubuntu, a mam Win 10 tylko do gier ;)

Bo maci/linuxy do multimediów ssą druta.

Kodeki do dźwięku/wideo, wsparcie dla wszystkich flac'ów, mkv'ów, photoshop'y, sony vegas'y, adobe premier'y, narzędzia do edycji dźwięku, wszystkie toole jak ffmpeg, edytowarki np napisów do filmów, nie mówiąc o DirectX'ach i OpenGL'ach do gier. Wszystko to zawsze śmiga out-of-the box na Windowsie. Stery n.p do tabletów graficznych i innych urządzeń się instalują praktycznie same. Dodatkowo pozostałe programy jak Hamachi np, Powłoka windows'owska jest dosyć edytowalna (z rejestrami i dodatkami w .NET).

Raz używałem Gimp'a na linuxie i myślałem że mnie c**** strzeli. To samo jak chciałem odpalić grę na Wine'ie. Panie, daj Pan spokój.

(każda platforma ma swoje plusy i minusy po prostu - bo np docker na Windowsie to ból. I jak widać git też :D).

1

Ogólnie nieźle się wrypałem :-)

Spróbowałem tego wsl2 - wyniki git w linux subystem były dobre...(patrz wcześniejszy post)
jedyny problem taki, że przestało działać vmware (a właściwie nested virtualization)

https://communities.vmware.com/thread/634674

Po dalszej walce jeden "workaround" zadziałał i vmware znowu żyje... ale windows linux subystem całkiem umar - nie działa nawet wolno.
Ogólnie lektura wątków wskazuje, że teraz mogę sobie wybrać - albo wls albo vmware - oba naraz nie zadziałają.

polecam ten system

1

A jakiego tego gita odpalasz, bo nie widzę? Bo może to np. Cygwin a nie sam git.

1

Nie wiem czy to jest przyczyna, ale kiedyś słyszałem że Linux i Mac jest dużo szybszy w wielu operacjach na małych plikach. Dlatego Android Studio działało lepiej na Mac Os niż na Windowsie.

0

Bo z uwagi na droższe miejsce na niewymienialnym SSD nikt normalny na Makówki nie pakuje repo ważących po kilkadziesiąt GB.

0

A sprawdzałeś stan zdrowia tego SSD w domu?
AFAIK one nie umierają tak szybko, tylko właśnie zwalniają.

1

Też to zauważyłam. Nasze repo ma niezbyt wiele, bo niecałe 500MB, na Windowsie operacje takie jak checkout, pull, czy chociażby zwykły git status potrafiły przywolnić niejednego proca. Odkąd mamy Maki, problemów brak

0

Nie rozumiem problemu. Wspolczesnie na windzie pracuje sie z wsl2 i predkosc dzialania jest w 100% rowna linuxowi, a od maca raczej szybsza, bo taka konfiguracja maca, jak moj pc kosztowalaby pewniw tyle co male mieszkanie. Nigdy zadna operacja na windowsie z gitem nie trwala u mnie dluzej niz 1-2 sek, zwykle ulamki sekund.

Ps. Z tego co patrzylem to kolo 80k, a ludzie skarza sie na chlodzenie.

2

Wspolczesnie na windzie pracuje sie z wsl2

Nie w banku, gdzie lapki są koszmarnie poblokowane.

i predkosc dzialania jest w 100% rowna linuxowi

Ale do tego to chyba trzeba mieć pliki na linuksowej partycji, bo na windowsowej dalej jest przecież powolny (obojętne z jakiego powodu) NTFS.

0

Ja zauważam różnice tylko podczas push i i fetch, ale to wynika z różnic konfiguracji.
Maszynę Windows dostałem skonfigurowaną i najraźniej tam git korzysta z IWA co daje spore opóźnienie.
macOS konfigurowałem sam używając ssh/RSA i komunikacja sieciowa idzie dużo sprawniej.

1
renderme napisał(a):

Nie rozumiem problemu. Wspolczesnie na windzie pracuje sie z wsl2

To nieprawda, ponieważ vmware ma problem z wsl2. (ma problem z hyper-v)
Generalnie musiałem powrócić do wsl1, problemów z dockerem itp.
vmware i możliwość pracy na czymś nie tak porypanym jak windows była ważniejsza.

EDIT:
zrobiłem sobie w zeszłym tygodzniu (w czwartek) dzień eksperymentalnej pracy z windows, ale ze wsparciem wsl2 (npm i inne)
kilka razy w jakiś cudowny sposób założył mi się folder którego nie mogłem usunąc nawet jako admin (pomagał restart systemu),
ze dwa razy coś się stało z plikami gita (pod wsl) - nie można było nic commitować (zablokowały się do zapisu) - cudownie (znowu restart windy i było ok)

jak ktoś działa na czystym win, w tym ich koszmarnym systemie plików i nie włazi w wsl to pewnie się da pracować ( w końcu npm / node da się też na windows odpalić)

ja poddałem sie gdzieś w 6tej godzinie

1

Zaraz przyjdzie @somekind i wam wyjaśni, czemu to Windows jest lepszy.

1

Odpowiedź jest prosta. Tylko w Polsce programiści siedzą masowo na PC i testują tutaj oprogramowanie. Wszędzie zagranicą siedzą na 13 calowych Macach w Starbucksach, popijając latte z mlekiem sojowym i dlatego jak coś im nie działa to poprawiają to pod Maca, a pod Windowsa tylko kompilują, nie testując tego nawet samemu dłużej niż 5 minut ewentualnie na wirtualnej maszynie ;).

Testuje teraz sprzęt z firmy Kensington (trackballe) to na Windowsie napotykam proste do naprawy problemy z ich sprzętem i oprogramowaniem, gdyby tylko ktoś spędził więcej niż tydzień czasu testując to na Windowsie, a ich problemy wynikają z tego, że w tej firmie wszyscy jadą na Macach, zrozumiałem to oglądając ich reklamy, w których nie zobaczysz nigdzie PC-ta.

0
Meini napisał(a):

Zaraz przyjdzie @somekind i wam wyjaśni, czemu to Windows jest lepszy.

WTF? Ja nawet tak nie uważam. Jakiś atak wtórnego analfabetyzmu?

0

git config --get core.fscache -- jeśli jest false/ empty, to:

git config --global core.fscache true

1

macOS:

  • Lepszy hardware (najszybsze SSD na rynku)
  • macOS wykorzystuje caly niewykorzystany RAM jako cache

Win:

  • NTFS ssie, komplacja java'y jest o wiele wolniejsza na NTFS'ie vs Ext3
  • Antywirus

Linux:

  • Moze ssac jak sa access time'y powlaczane na FS (file last access time). Najlepiej wszystko wylaczyc i pogodzic sie z tym ze nie bedzie modified time dostepny na plikach. Bedzie smigac.

1 użytkowników online, w tym zalogowanych: 0, gości: 1