iMacedonean
Poster original- 10 octombrie 2015
- Brno, CZ
- 15 decembrie 2018
Mă gândesc serios să cumpăr un MacBook Pro 13' 2018. Utilizarea principală a laptopului ar fi pentru codare (dezvoltare web front-end), dar aș dori să mă arunc mai târziu în dezvoltarea aplicației iOS. Acestea fiind spuse, sunt suficiente 8 GB de RAM pentru a rula XCODE sau ar trebui să investesc mai mult pentru a obține versiunea de 16 GB?
revmacian
- 20 octombrie 2018
- UTILIZĂRI
- 15 decembrie 2018
iMacedonian a spus: Bună.Rulez Xcode pe Mac mini din 2014 - are 4 GB RAM și nu văd probleme. Vor fi unii oameni care vă vor spune că 16 GB sau mai mult RAM este o necesitate, dar am văzut că acest lucru pur și simplu nu este adevărat.
Mă gândesc serios să cumpăr un MacBook Pro 13' 2018. Utilizarea principală a laptopului ar fi pentru codare (dezvoltare web front-end), dar aș dori să mă arunc mai târziu în dezvoltarea aplicației iOS. Acestea fiind spuse, sunt suficiente 8 GB de RAM pentru a rula XCODE sau ar trebui să investesc mai mult pentru a obține versiunea de 16 GB?
Emanuel rodriguez
- 17 octombrie 2018
- 15 decembrie 2018
revmacian a spus: Eu rulez Xcode pe Mac mini din 2014 - are 4 GB RAM și nu văd probleme. Vor fi unii oameni care vă vor spune că 16 GB sau mai mult RAM este o necesitate, dar am văzut că acest lucru pur și simplu nu este adevărat.De acord. Am descoperit că chiar și un Raspberry Pi cu un singur gig de RAM este capabil să compileze majoritatea lucrurilor. Dacă un proiect are o mulțime de cod C++ (văzându-vă LLVM) sau alte limbaje complexe (care necesită ca compilatorul să lucreze din greu și, astfel, să folosească mai multă RAM), atunci în general nu îl poate gestiona. Din experiența mea, se pare că aproximativ 3 GB este un minim sigur pentru munca de dezvoltare.
EDIT: Deși rețineți că acesta a fost 3 GB în interiorul unui VM, fără GUI. Opțiunea de 8 GB este cu siguranță sigură, deocamdată. Totuși, aș recomanda 16 GB doar pentru protejarea viitorului. 8GB începe să devină mai puțin confortabil decât în trecut. Ultima modificare: 15 decembrie 2018
amulder
- 18 decembrie 2015
- 16 decembrie 2018
slob de câine
- 19 octombrie 2014
- Apple Campus, Cupertino CA
- 16 decembrie 2018
960design
- 17 aprilie 2012
- Destiny, FL
- 17 decembrie 2018
iMacedonian a spus: Bună.8 GB este suficient, folosesc un MBPr de 16 GB și rareori văd presiunea memoriei sări peste 8 GB.
Mă gândesc serios să cumpăr un MacBook Pro 13' 2018. Utilizarea principală a laptopului ar fi pentru codare (dezvoltare web front-end), dar aș dori să mă arunc mai târziu în dezvoltarea aplicației iOS. Acestea fiind spuse, sunt suficiente 8 GB de RAM pentru a rula XCODE sau ar trebui să investesc mai mult pentru a obține versiunea de 16 GB?
Deoparte, verificați pe Expo.io ( https://expo.io/ ). Este ceea ce folosesc toți copiii cool în aceste zile (mult mai ușor de implementat pe mai multe platforme). Avertisment: va funcționa pentru majoritatea aplicațiilor, dar unele au cerințe / nevoi hardware specifice pe care expo nu le va îndeplini. Cu toate acestea, un loc de plecare fantastic.
jtara
- 23 aprilie 2009
- 17 decembrie 2018
Vrei să spui „suficient pentru ca build-urile să nu eșueze?”
Sau „suficient pentru a se construi complet într-un interval de timp acceptabil”?
Și/sau suficient pentru ca interfața de utilizare să nu fie întârziată și să pot lucra într-un editor/să navighez pe web/să citesc e-mailurile în timpul unei build fără încetinire?
Depinde de așteptările tale și de lanțul tău de instrumente.
Dezvoltarea front-end are de obicei un lanț de instrumente scurt/simplu. Tot ce ai nevoie este un editor bun, potrivit pentru sarcină, un mic server web „jucărie”, poate câteva instrumente pentru minimizarea Javascript/CSS (și poate un compilator Sass) pentru versiuni de producție, iar în timpul dezvoltării, de obicei, nici măcar nu ai folosi acea.
Dezvoltarea backend poate avea nevoie adesea de nu mai mult decât dezvoltarea front-end. Sau ar putea avea nevoie de ceva mai mult. De exemplu, folosesc PostgreSQL ca bază de date. Deci, am o instanță locală pentru dezvoltare/testare. Rulez pgAdmin4, care rulează într-un container Docker. S-ar putea să fie nevoie să rulați o VM care să reproducă mediul backend. GB se adună.
Dezvoltarea aplicației native se face adesea cu instrumente minime. Pentru dezvoltarea de bază a aplicației iOS, nu aveți nevoie de nimic mai mult decât Xcode. OK, și simulatorul iOS. Dacă faceți un fel de dezvoltare hibridă, multiplatformă, probabil adăugați componente suplimentare pentru lanțul de instrumente - și, în mod necesar, SDK-uri Android și instrumente de construcție. Dezvoltarea Android folosește un compilator diferit. Adăugați un alt simulator. (Folosesc GenyMotion, deoarece ambele abordări oferite de Google sunt lente ca melasa.) Orice simulator Android decent rulează într-un VM.
Oh, trebuie să testezi acel site pe Windows? Adăugați un VM Windows.
Atât de multe instrumente rulează astăzi într-un container sau într-un VM. Asta se adaugă la cerința de memorie.
Obțineți câtă memorie poate suporta bugetul dvs. Cred, totuși, 64 GB este limita practică astăzi pentru majoritatea dezvoltării. Am primit recent un iMac Pro cu 64 GB pentru dezvoltare. Folosesc un set mare de instrumente. Am verificat Monitorul de activitate și constat că nu am folosit încă un fișier de schimb. Dar odată ce toate instrumentele sunt încărcate, folosesc undeva între 32 GB și 64 GB, de obicei 40-50 GB. Dar de fapt nu am încărcat TOTUL deodată.
Ceea ce trebuie să vă întrebați este:
- Este important ca sistemul să răspundă în timpul construcției?
- Cât de lung dintr-un ciclu de construcție sunteți dispus să tolerați?
În dezvoltarea front-end, de obicei nu aveți un „ciclu de construire”, adică build/test/repeat. Cât timp ești dispus să aștepți pentru a afla că ai făcut o greșeală simplă, care va dura câteva secunde pentru a fi corectată? 15 minute? 5 minute? 1 minut? 30 de secunde?
În dezvoltarea de aplicații folosind un limbaj compilat, aveți întotdeauna un ciclu de construire și poate fi semnificativ. Înțeleg că ciclul de construire Swift este substanțial mai lung decât ciclul de construire Objective-C. (Eu nu folosesc Swift, deoarece fac dezvoltare hibridă, iar codul platformei de bază este în Objective-C (Java pentru Android), C și C++ - fără Swift).
Cantitatea de RAM disponibilă va avea un impact semnificativ asupra duratei ciclului de construire.
mpe
- 3 septembrie 2010
- 17 decembrie 2018
Da. 8 GB RAM este suficient pentru majoritatea lucrurilor.
jtara
- 23 aprilie 2009
- 17 decembrie 2018
mpe a spus: Da. 8 GB RAM este suficient pentru majoritatea lucrurilor.
MacBook Pro folosește memoria de sistem pentru afișaj?
8 GB cu siguranță nu este suficient pe - de exemplu - un Mac Mini, deoarece o bucată destul de bună (în funcție de model) este folosită pentru afișaj.
Cel mai important feedback oferit aici este că pe MacBook-urile recente, memoria este lipită. Luați o decizie pentru următorii câțiva ani.
Toutou
la
- 6 ianuarie 2015
- Praga, Republica Ceha
- 17 decembrie 2018
iMacedonean
Poster original- 10 octombrie 2015
- Brno, CZ
- 17 decembrie 2018
jtara a spus: Definiți ce înțelegeți prin „destul”?Mulțumesc pentru răspunsul amplu, mi-a oferit o perspectivă mai bună asupra resurselor necesare pentru aceste diferite scenarii de codare pe care le-ați menționat.
Vrei să spui „suficient pentru ca build-urile să nu eșueze?”
Sau „suficient pentru a se construi complet într-un interval de timp acceptabil”?
Și/sau suficient pentru ca interfața de utilizare să nu fie întârziată și să pot lucra într-un editor/să navighez pe web/să citesc e-mailurile în timpul unei build fără încetinire?
Depinde de așteptările tale și de lanțul tău de instrumente.
Dezvoltarea front-end are de obicei un lanț de instrumente scurt/simplu. Tot ce ai nevoie este un editor bun, potrivit pentru sarcină, un mic server web „jucărie”, poate câteva instrumente pentru minimizarea Javascript/CSS (și poate un compilator Sass) pentru versiuni de producție, iar în timpul dezvoltării, de obicei, nici măcar nu ai folosi acea.
Dezvoltarea backend poate avea nevoie adesea de nu mai mult decât dezvoltarea front-end. Sau ar putea avea nevoie de ceva mai mult. De exemplu, folosesc PostgreSQL ca bază de date. Deci, am o instanță locală pentru dezvoltare/testare. Rulez pgAdmin4, care rulează într-un container Docker. S-ar putea să fie nevoie să rulați o VM care să reproducă mediul backend. GB se adună.
Dezvoltarea aplicației native se face adesea cu instrumente minime. Pentru dezvoltarea de bază a aplicației iOS, nu aveți nevoie de nimic mai mult decât Xcode. OK, și simulatorul iOS. Dacă faceți un fel de dezvoltare hibridă, multiplatformă, probabil adăugați componente suplimentare pentru lanțul de instrumente - și, în mod necesar, SDK-uri Android și instrumente de construcție. Dezvoltarea Android folosește un compilator diferit. Adăugați un alt simulator. (Folosesc GenyMotion, deoarece ambele abordări oferite de Google sunt lente ca melasa.) Orice simulator Android decent rulează într-un VM.
Oh, trebuie să testezi acel site pe Windows? Adăugați un VM Windows.
Atât de multe instrumente rulează astăzi într-un container sau într-un VM. Asta se adaugă la cerința de memorie.
Obțineți câtă memorie poate suporta bugetul dvs. Cred, totuși, 64 GB este limita practică astăzi pentru majoritatea dezvoltării. Am primit recent un iMac Pro cu 64 GB pentru dezvoltare. Folosesc un set mare de instrumente. Am verificat Monitorul de activitate și constat că nu am folosit încă un fișier de schimb. Dar odată ce toate instrumentele sunt încărcate, folosesc undeva între 32 GB și 64 GB, de obicei 40-50 GB. Dar de fapt nu am încărcat TOTUL deodată.
Ceea ce trebuie să vă întrebați este:
- Este important ca sistemul să răspundă în timpul construcției?
- Cât de lung dintr-un ciclu de construcție sunteți dispus să tolerați?
În dezvoltarea front-end, de obicei nu aveți un „ciclu de construire”, adică build/test/repeat. Cât timp ești dispus să aștepți pentru a afla că ai făcut o greșeală simplă, care va dura câteva secunde pentru a fi corectată? 15 minute? 5 minute? 1 minut? 30 de secunde?
În dezvoltarea de aplicații folosind un limbaj compilat, aveți întotdeauna un ciclu de construire și poate fi semnificativ. Înțeleg că ciclul de construire Swift este substanțial mai lung decât ciclul de construire Objective-C. (Eu nu folosesc Swift, deoarece fac dezvoltare hibridă, iar codul platformei de bază este în Objective-C (Java pentru Android), C și C++ - fără Swift).
Cantitatea de RAM disponibilă va avea un impact semnificativ asupra duratei ciclului de construire.
[doublepost=1545084766][/doublepost]
amulder a spus: Cât timp plănuiți să păstrați mașina? Deoarece memoria nu poate fi actualizată, chiar cumpărați pentru câtă memorie veți avea nevoie în 3-5 ani, nu astăzi. (Ținând cont de faptul că fiecare lansare de instrumente de dezvoltare utilizează mai multă memorie decât ultima.) În special dacă ajungeți să utilizați containere sau mașini virtuale (de exemplu, pentru a rula o versiune locală a unui back-end la care se conectează aplicația), impactul de productivitate al prea puțină memorie mai târziu nu merită economiile de costuri acum.Laptopul meu durează de obicei 4-6 ani, sau chiar mai mult, așa că pe baza a ceea ce am citit până acum, poate că cel mai bine ar fi să iau versiunea de 16 GB dacă vreau să maximizez utilizarea. LA
Soarece anonim
- 25 august 2016
- 17 decembrie 2018
jtara a spus: Definiți ce înțelegeți prin „destul”?
(croitor)
Atât de multe instrumente rulează astăzi într-un container sau într-un VM. Asta se adaugă la cerința de memorie.
Obțineți câtă memorie poate suporta bugetul dvs. Cred, totuși, 64 GB este limita practică astăzi pentru majoritatea dezvoltării. Am primit recent un iMac Pro cu 64 GB pentru dezvoltare. Folosesc un set mare de instrumente. Am verificat Monitorul de activitate și constat că nu am folosit încă un fișier de schimb. Dar odată ce toate instrumentele sunt încărcate, folosesc undeva între 32 GB și 64 GB, de obicei 40-50 GB. Dar de fapt nu am încărcat TOTUL deodată.
Ceea ce trebuie să vă întrebați este:
- Este important ca sistemul să răspundă în timpul construcției?
- Cât de lung dintr-un ciclu de construcție sunteți dispus să tolerați?
În dezvoltarea front-end, de obicei nu aveți un „ciclu de construire”, adică build/test/repeat. Cât timp ești dispus să aștepți pentru a afla că ai făcut o greșeală simplă, care va dura câteva secunde pentru a fi corectată? 15 minute? 5 minute? 1 minut? 30 de secunde?
În dezvoltarea de aplicații folosind un limbaj compilat, aveți întotdeauna un ciclu de construire și poate fi semnificativ. Înțeleg că ciclul de construire Swift este substanțial mai lung decât ciclul de construire Objective-C. (Eu nu folosesc Swift, deoarece fac dezvoltare hibridă, iar codul platformei de bază este în Objective-C (Java pentru Android), C și C++ - fără Swift).
Cantitatea de RAM disponibilă va avea un impact semnificativ asupra duratei ciclului de construire.
Acest lucru rezumă destul de mult. Dacă trebuie să rulați VM-uri, atunci 8 GB sunt realizabili (puteți rula un VM confortabil în 8 GB RAM). Dacă aveți un SSD, diferența de viteză dintre a avea 8 GB față de mai multă RAM nu va fi foarte evidentă decât dacă rulați un număr mare de VM și/sau încercați să compilați o bază de cod uriașă. C
Construi
- 23 iunie 2010
- 17 decembrie 2018
Aplicațiile care au nevoie de memorie precum XCode și Android Studio se vor descurca bine în 8 GB. Problema ar veni dacă ați încerca să rulați Slack conectat la mai multe grupuri, lăsând Chrome deschis cu numeroase file sau poate un sistem VM pentru a rula niște containere Docker. Concurența este cea care provoacă probleme.
Dacă vă puteți permite săriți la 16 GB și intenționați să păstrați această mașină pentru o vreme, cred că merită pe deplin pentru a fi sigură pentru viitor. Dacă costul suplimentar este suficient pentru a vă face să vă gândiți de două ori, atunci uitați de el și faceți doar 8 GB. Vei fi fericit oricum.
revmacian
- 20 octombrie 2018
- UTILIZĂRI
- 17 decembrie 2018
jtara a spus: 8 GB cu siguranță nu este suficient pe - de exemplu - un Mac Mini, deoarece o bucată destul de bună (în funcție de model) este folosită pentru afișaj.
După cum am spus mai devreme, rulez Xcode pe Mac mini din 2014 - are 4 GB RAM și nu văd nicio problemă. Dacă pot codifica confortabil cu 4 GB, atunci 8 GB este suficient. J
jtara
- 23 aprilie 2009
- 30 decembrie 2018
kadammanali987 a spus: (Oamenii păstrează adesea aplicația pentru compilare și joacă jocuri până în acel moment. Acest lucru încetinește procesarea)
Sau ai putea doar să accelerezi ciclul de compilare-link-run până la punctul în care nu este nevoie de mai mult de o ridicare sănătoasă de pe scaun pentru câteva minute.
O parte din aceasta este să aveți suficientă memorie pentru ca compilatorul să funcționeze eficient, cu schimburi minime/fără.
Că POȚI nu înseamnă că TREBUIE. Trebuie să decizi cât de valoros este timpul tău.
Momentul definitoriu pentru această ecuație pentru mine a fost acum mulți, mulți ani. Un produs numit Instant-C. A redus acel ciclu de la câteva minute la câteva secunde. M-a inspirat să reduc un ciclu de compilare-link-run pentru o aplicație care simulează și analizează variații (de la un model, scris inițial în Fortran) în ansamblurile mecanice de la 1/2 oră la mai puțin de un minut. (OK, am trișat - am eliminat ciclul compilare-link-run... scriind un compilator specific domeniului și un interpret de cod de octet însoțitor) 35 de ani mai târziu, este încă soluția predominantă pentru acel domeniu.
Oricum, OP și-a luat decizia - cred că una înțeleaptă.
BTW, dacă aș folosi în continuare i7 Mini-ul meu 2012 pentru versiuni, aș folosi un Ramdisk. Aproximativ înjumătățit timpul de construcție pentru mine pe Mini. L-am încercat pe noul meu iMac Pro, dar nu a avut același impact. Mă tem că nu m-am gândit să încerc discul ram până când am primit iMac Pro. MacOS nu are cu adevărat soluții RamDisk grozave. Mini are 16 GB. Nu există marjă pentru un disc ram pe o mașină cu 4 GB. (iMac Pro are 64 GB).
vbctv
la
- 25 septembrie 2013
- Cleveland, OH
- 2 mai 2019
jtara a spus: MacBook Pro folosește memoria de sistem pentru afișaj?
8 GB cu siguranță nu este suficient pe - de exemplu - un Mac Mini, deoarece o bucată destul de bună (în funcție de model) este folosită pentru afișaj.
Cel mai important feedback oferit aici este că pe MacBook-urile recente, memoria este lipită. Luați o decizie pentru următorii câțiva ani.
Am un mac Mini 2018 conectat la 2 monitoare și am 8 GB RAM, nu văd niciodată probleme și fac atât munca de dezvoltare Android Studio, cât și Xcode și rulez MAMP Pro în fundal. Monitorul de presiune al memoriei nu crește niciodată cu adevărat și rămâne întotdeauna verde și scăzut. Am dezbătut o actualizare la 16 GB, dar nu văd cu adevărat o nevoie decât dacă găsesc o afacere ucigașă la vânzare... C
ChromeCloud
- 21 iunie 2009
- Italia
- 2 mai 2019
Când încerc să-mi folosesc MacBook Air cu 4 GB de RAM pentru a dezvolta aplicații iOS (vorbesc de aplicații reale, nu doar de mici proiecte demonstrative), experiența devine destul de frustrantă, foarte repede. Doar deschiderea Xcode și Safari cu 3 sau 4 file vă va satura complet RAM (rețineți că sistemul în sine durează aproximativ 2 GB) și utilizarea simulatorului pentru a vă depana aplicațiile este aproape imposibilă (computerul încetinește până la punctul de a nu răspunde).
Cu 8 GB vei fi bine. Dar nu pentru mult timp. Să presupunem că 8 GB este minimul pentru a rula confortabil suita completă de dezvoltare iOS + câteva aplicații pe lateral dacă doriți să aveți un editor de text elegant sau câteva instrumente pentru a face grafică vectorială, de exemplu.
Deci, dacă ar trebui să cumpăr o mașină nouă acum și să o păstrez pentru următorii 3 ani sau mai mult, aș primi cel puțin 16 GB de RAM.
Un alt cuvânt de precauție: nu aș fi anticipat niciodată acest lucru acum câțiva ani când mi-am cumpărat iMac-ul (care are 32 GB de RAM și este stația mea de lucru principală), dar se pare că dacă doriți să rulați simulatorul fără ca întreaga GUI să se bâlbâie, VRAM (aka video memory) joacă, de asemenea, un rol important în ecuație.
Pentru un iMac cu retina, o placă video de 2 GB nu va fi suficientă pentru a rula totul fără probleme: la fiecare câteva secunde, tamponul se umple (totuși, experimentez asta doar în timp ce rulez simulatorul) și iMac-ul se blochează pentru o fracțiune de secundă în timp ce acesta se golește și se umple din nou. Este super enervant.
Așa că recomandarea mea pentru ceva la care poți lucra confortabil în următorii 3 ani este: 16 GB de RAM (sau mai mult) + 4 GB de VRAM (sau mai mult) .
mkelly
- 29 noiembrie 2007
- 3 mai 2019
mulţimile
- 12 februarie 2019
- 4 mai 2019
În aceeași aplicație, pot vedea că utilizarea RAM este sub 8 GB fără schimb. Pentru mai târziu, mă gândesc să actualizez memoria RAM, dar nu mă grăbesc momentan. F
Filipeteixeira
- 10 aprilie 2013
- 6 mai 2019
Posturi Populare