Foorumit

Riittääkö 8 Gt RAM-muistia ohjelmointiin?

iMakedonia

Alkuperäinen juliste
10. lokakuuta 2015
Brno, CZ
  • 15. joulukuuta 2018
Hei siellä.

Harkitsen vakavasti MacBook Pro 13' 2018:n hankkimista. Kannettavan tietokoneen ensisijainen käyttötarkoitus olisi koodaukseen (etuosan verkkokehitykseen), mutta haluaisin sukeltaa myöhemmin iOS-sovelluskehitykseen. Riittääkö 8 Gt RAM-muistia XCODE:n suorittamiseen vai pitäisikö minun investoida enemmän saadakseni 16 Gt:n version?

revmacian

20. lokakuuta 2018


KÄYTTÖT
  • 15. joulukuuta 2018
iMacedonian sanoi: Hei.

Harkitsen vakavasti MacBook Pro 13' 2018:n hankkimista. Kannettavan tietokoneen ensisijainen käyttötarkoitus olisi koodaukseen (etuosan verkkokehitykseen), mutta haluaisin sukeltaa myöhemmin iOS-sovelluskehitykseen. Riittääkö 8 Gt RAM-muistia XCODE:n suorittamiseen vai pitäisikö minun investoida enemmän saadakseni 16 Gt:n version?
Käytän Xcodea 2014 Mac minissäni - siinä on 4 Gt RAM-muistia, enkä näe mitään ongelmia. Jotkut ihmiset sanovat, että 16 Gt tai enemmän RAM-muistia on pakollinen, mutta olen nähnyt, että tämä ei yksinkertaisesti pidä paikkaansa.
Reaktiot:jeremiah256, racerhomie, BigMcGuire ja 1 muu henkilö

Emanuel rodriguez

17. lokakuuta 2018
  • 15. joulukuuta 2018
revmacian sanoi: Käytän Xcodea vuoden 2014 Mac minissäni - siinä on 4 Gt RAM-muistia, enkä näe mitään ongelmia. Jotkut ihmiset sanovat, että 16 Gt tai enemmän RAM-muistia on pakollinen, mutta olen nähnyt, että tämä ei yksinkertaisesti pidä paikkaansa.
Sovittu. Olen huomannut, että jopa Raspberry Pi, jolla on yksi keikka RAM-muistia, pystyy kokoamaan useimmat asiat. Jos projektissa on paljon C++-koodia (LLVM-koodia katsottuna) tai muita monimutkaisia ​​kieliä (jotka edellyttävät kääntäjän työskentelyä kovasti ja siten enemmän RAM-muistia), se ei yleensä pysty hallitsemaan sitä. Noin 3 Gt näyttää olevan kokemukseni mukaan turvallinen minimi kehitystyöhön.

EDIT: Muista kuitenkin, että tämä oli 3 Gt VM:n sisällä ilman graafista käyttöliittymää. 8GB vaihtoehto on toistaiseksi ehdottomasti turvallinen. Suosittelisin 16 Gt vain tulevaisuuden varalta. 8 Gt alkaa olla vähemmän mukava kuin ennen. Viimeksi muokattu: 15.12.2018
Reaktiot:BigMcGuire, jaduff46 ja iMakedonia TO

patruuna

18. joulukuuta 2015
  • 16. joulukuuta 2018
Kauanko aiot pitää konetta? Koska muistia ei voi päivittää, ostat todella sen verran, kuinka paljon muistia tarvitset 3–5 vuoden kuluttua, ei tänään. (Pitää mielessä, että jokainen kehitystyökalujen julkaisu kuluttaa enemmän muistia kuin edellinen.) Varsinkin jos päädyt käyttämään säilöjä tai virtuaalikoneita (esim. käyttääksesi paikallista versiota jostakin taustaohjelmasta, johon sovelluksesi muodostaa yhteyden), tuottavuusosuma liian vähän muistia myöhemmin ei ole kustannussäästöjen arvoista nyt.
Reaktiot:jeremiah256, racerhomie, iMacedonian ja 1 muu henkilö

koiranlokero

19. lokakuuta 2014
Apple Campus, Cupertino CA
  • 16. joulukuuta 2018
Muista ohjelmointi 4K-muodossa vuonna 1976.
Reaktiot:PhilMacbook

960 design

17. huhtikuuta 2012
Destiny, FL
  • 17. joulukuuta 2018
iMacedonian sanoi: Hei.

Harkitsen vakavasti MacBook Pro 13' 2018:n hankkimista. Kannettavan tietokoneen ensisijainen käyttötarkoitus olisi koodaukseen (etuosan verkkokehitykseen), mutta haluaisin sukeltaa myöhemmin iOS-sovelluskehitykseen. Riittääkö 8 Gt RAM-muistia XCODE:n suorittamiseen vai pitäisikö minun investoida enemmän saadakseni 16 Gt:n version?
8 Gt riittää, käytän 16 Gt MBPr:tä ja näen harvoin muistin paineen hyppäävän yli 8 Gt.

Tarkista myös Expo.io ( https://expo.io/ ). Sitä kaikki siistit lapset käyttävät nykyään (niin paljon helpompi ottaa käyttöön useilla alustoilla). Varoitus: toimii useimmissa sovelluksissa, mutta joillakin on erityisiä laitteistovaatimuksia/tarpeita, joita expo ei täytä. Siitä huolimatta loistava aloituspaikka.
Reaktiot:iMakedonia J

jtara

23. huhtikuuta 2009
  • 17. joulukuuta 2018
Määrittele mitä tarkoitat 'riittävästi'?

Tarkoitatko 'tarpeeksi, jotta rakennukset eivät epäonnistu?'

Tai 'riittävästi, jotta rakennukset valmistuvat hyväksyttävässä ajassa'?

Ja/tai tarpeeksi, jotta käyttöliittymä ei ole viive, ja voin työskennellä editorissa/selailla verkkoa/lukea sähköpostia rakentamisen aikana ilman hitautta?

Se riippuu odotuksistasi ja työkaluketjustasi.

Käyttöliittymäkehityksessä on tyypillisesti lyhyt/yksinkertainen työkaluketju. Tarvitset vain tehtävään sopivan hyvän editorin, pienen 'lelu'-web-palvelimen, ehkä työkaluja Javascriptin/CSS:n minimoimiseen (ja ehkä Sass-kääntäjän) tuotantorakennuksia varten, joita et tyypillisesti käyttäisi kehityksen aikana. että.

Taustakehitys voi usein tarvita vain etupään kehittämistä. Tai ehkä tarvitaan vähän enemmän. Käytän esimerkiksi PostgreSQL:ää tietokantana. Joten minulla on paikallinen esimerkki kehitystä/testausta varten. Suoritan pgAdmin4:n, joka toimii Docker-säiliössä. Sinun on ehkä käytettävä virtuaalikonetta, joka replikoi taustaympäristösi. GB lasketaan yhteen.

Natiivisovellusten kehitys tehdään usein minimaalisilla työkaluilla. iOS-sovelluksen peruskehitykseen tarvitset vain Xcoden. OK, ja iOS-simulaattori. Jos olet tekemässä jonkinlaista hybridi-alustojen välistä kehitystä, lisää luultavasti työkaluketjun lisäkomponentteja - ja välttämättä Android SDK:ita ja rakennustyökaluja. Android-kehitys käyttää eri kääntäjää. Lisää toinen simulaattori. (Käytän GenyMotionia, koska molemmat Googlen tarjoamat lähestymistavat ovat hitaita kuin melassi.) Mikä tahansa kunnollinen Android-simulaattori toimii virtuaalikoneessa.

Pitääkö tuota verkkosivustoa testata Windowsissa? Lisää Windows VM.

Niin monet työkalut toimivat nykyään säiliössä tai virtuaalikoneessa. Se lisää muistin tarvetta.

Hanki niin paljon muistia kuin budjettisi kestää. Luulen kuitenkin, että 64 Gt on nykyään käytännöllinen rajoitus suurimmalle osalle kehitystyötä. Sain äskettäin iMac Pron, jossa on 64 Gt kehitystä varten. Käytän isoa työkalusarjaa. Olen tarkistanut Activity Monitorin ja huomaan, että en ole vielä käyttänyt swap-tiedostoa. Mutta kun kaikki työkalut on ladattu, käytän jossain 32 Gt ja 64 Gt välillä, tyypillisesti 40-50 Gt. Mutta itse asiassa en ole vielä ladannut KAIKKEA kerralla.

Mitä sinun on kysyttävä itseltäsi, on:

- Onko tärkeää, että järjestelmä reagoi rakentamisen aikana?
- Kuinka pitkän rakennussyklin olet valmis sietämään?

Käyttöliittymäkehityksessä sinulla ei tyypillisesti ole 'koontisykliä', eli rakentaa/testaa/toista. Kuinka kauan olet valmis odottamaan saadaksesi selville, että teit yksinkertaisen virheen, jonka korjaaminen kestää muutaman sekunnin? 15 minuuttia? 5 minuuttia? 1 minuutti? 30 sekuntia?

Käännettyä kieltä käyttävässä sovelluskehityksessä sinulla on aina rakennussykli, ja se voi olla merkittävä. Ymmärrän, että Swift-rakennussykli on huomattavasti pidempi kuin Objective-C-koontisykli. (En käytä Swiftiä itse, koska teen hybridikehitystä, ja taustalla oleva alustakoodi on Objective-C:ssä (Java Androidille), C:ssä ja C++:ssa - ei Swiftiä).

Käytettävissä olevan RAM-muistin määrällä on merkittävä vaikutus rakennusjaksoaikaan.
Reaktiot:tegranjeet, quietstormSD, Anony-mouse ja 1 muu henkilö M

mpe

3. syyskuuta 2010
  • 17. joulukuuta 2018
32 Gt iMac Pron käyttäjä täällä.

Joo. 8 Gt RAM-muistia riittää useimpiin asioihin.
Reaktiot:iMakedonia J

jtara

23. huhtikuuta 2009
  • 17. joulukuuta 2018
mpe sanoi: Kyllä. 8 Gt RAM-muistia riittää useimpiin asioihin.

Käyttääkö MacBook Pro järjestelmämuistia näytölle?

8 Gt ei varmasti riitä - esimerkiksi - Mac Minissä, sillä aika hyvä osa (mallista riippuen) siitä käytetään näyttöön.

Tärkein tässä annettu palaute on, että viimeaikaisissa MacBookeissa muisti on juotettu alas. Teet päätöksen seuraaville vuosille.
Reaktiot:iMakedonia

Toutou

to
6. tammikuuta 2015
Praha, Tšekin tasavalta
  • 17. joulukuuta 2018
Jos olet budjetissa (ja siinä ei ole mitään häpeää), 8 keikkaa riittää. Vaikka jotkin kehitystyökalut ovat melko raskaita RAM-muistia (*yskä* Android Studio *yskä*), neljän keikan 2013 Proni on edelleen käyttökelpoinen. Ja työni julkaisema ThinkPad, jolla teen Rails-kehitystä (RubyMinessa, Linuxissa), toimii kuin hurmaa 8 keikan kanssa.
Reaktiot:iMakedonia

iMakedonia

Alkuperäinen juliste
10. lokakuuta 2015
Brno, CZ
  • 17. joulukuuta 2018
jtara sanoi: Määrittele mitä tarkoitat 'riittävästi'?

Tarkoitatko 'tarpeeksi, jotta rakennukset eivät epäonnistu?'

Tai 'riittävästi, jotta rakennukset valmistuvat hyväksyttävässä ajassa'?

Ja/tai tarpeeksi, jotta käyttöliittymä ei ole viive, ja voin työskennellä editorissa/selailla verkkoa/lukea sähköpostia rakentamisen aikana ilman hitautta?

Se riippuu odotuksistasi ja työkaluketjustasi.

Käyttöliittymäkehityksessä on tyypillisesti lyhyt/yksinkertainen työkaluketju. Tarvitset vain tehtävään sopivan hyvän editorin, pienen 'lelu'-web-palvelimen, ehkä työkaluja Javascriptin/CSS:n minimoimiseen (ja ehkä Sass-kääntäjän) tuotantorakennuksia varten, joita et tyypillisesti käyttäisi kehityksen aikana. että.

Taustakehitys voi usein tarvita vain etupään kehittämistä. Tai ehkä tarvitaan vähän enemmän. Käytän esimerkiksi PostgreSQL:ää tietokantana. Joten minulla on paikallinen esimerkki kehitystä/testausta varten. Suoritan pgAdmin4:n, joka toimii Docker-säiliössä. Sinun on ehkä käytettävä virtuaalikonetta, joka replikoi taustaympäristösi. GB lasketaan yhteen.

Natiivisovellusten kehitys tehdään usein minimaalisilla työkaluilla. iOS-sovelluksen peruskehitykseen tarvitset vain Xcoden. OK, ja iOS-simulaattori. Jos olet tekemässä jonkinlaista hybridi-alustojen välistä kehitystä, lisää luultavasti työkaluketjun lisäkomponentteja - ja välttämättä Android SDK:ita ja rakennustyökaluja. Android-kehitys käyttää eri kääntäjää. Lisää toinen simulaattori. (Käytän GenyMotionia, koska molemmat Googlen tarjoamat lähestymistavat ovat hitaita kuin melassi.) Mikä tahansa kunnollinen Android-simulaattori toimii virtuaalikoneessa.

Pitääkö tuota verkkosivustoa testata Windowsissa? Lisää Windows VM.

Niin monet työkalut toimivat nykyään säiliössä tai virtuaalikoneessa. Se lisää muistin tarvetta.

Hanki niin paljon muistia kuin budjettisi kestää. Luulen kuitenkin, että 64 Gt on nykyään käytännöllinen rajoitus suurimmalle osalle kehitystyötä. Sain äskettäin iMac Pron, jossa on 64 Gt kehitystä varten. Käytän isoa työkalusarjaa. Olen tarkistanut Activity Monitorin ja huomaan, että en ole vielä käyttänyt swap-tiedostoa. Mutta kun kaikki työkalut on ladattu, käytän jossain 32 Gt ja 64 Gt välillä, tyypillisesti 40-50 Gt. Mutta itse asiassa en ole vielä ladannut KAIKKEA kerralla.

Mitä sinun on kysyttävä itseltäsi, on:

- Onko tärkeää, että järjestelmä reagoi rakentamisen aikana?
- Kuinka pitkän rakennussyklin olet valmis sietämään?

Käyttöliittymäkehityksessä sinulla ei tyypillisesti ole 'koontisykliä', eli rakentaa/testaa/toista. Kuinka kauan olet valmis odottamaan saadaksesi selville, että teit yksinkertaisen virheen, jonka korjaaminen kestää muutaman sekunnin? 15 minuuttia? 5 minuuttia? 1 minuutti? 30 sekuntia?

Käännettyä kieltä käyttävässä sovelluskehityksessä sinulla on aina rakennussykli, ja se voi olla merkittävä. Ymmärrän, että Swift-rakennussykli on huomattavasti pidempi kuin Objective-C-koontisykli. (En käytä Swiftiä itse, koska teen hybridikehitystä, ja taustalla oleva alustakoodi on Objective-C:ssä (Java Androidille), C:ssä ja C++:ssa - ei Swiftiä).

Käytettävissä olevan RAM-muistin määrällä on merkittävä vaikutus rakennusjaksoaikaan.
Kiitos laajasta vastauksesta, se antoi minulle paremman näkökulman näihin mainitsemiisi koodausskenaarioihin tarvittaviin resursseihin.
[doublepost=1545084766][/doublepost]
ammulder sanoi: Kuinka kauan aiot pitää konetta? Koska muistia ei voi päivittää, ostat todella sen verran, kuinka paljon muistia tarvitset 3–5 vuoden kuluttua, ei tänään. (Pitää mielessä, että jokainen kehitystyökalujen julkaisu kuluttaa enemmän muistia kuin edellinen.) Varsinkin jos päädyt käyttämään säilöjä tai virtuaalikoneita (esim. käyttääksesi paikallista versiota jostakin taustaohjelmasta, johon sovelluksesi muodostaa yhteyden), tuottavuusosuma liian vähän muistia myöhemmin ei ole kustannussäästöjen arvoista nyt.
Kannettavat tietokoneeni kestävät yleensä 4-6 vuotta tai jopa enemmän, joten tähän mennessä lukemani perusteella ehkä olisi parasta hankkia 16 Gt:n versio, jos haluan maksimoida käytön. TO

Nimetön hiiri

25. elokuuta 2016
  • 17. joulukuuta 2018
jtara sanoi: Määrittele mitä tarkoitat 'riittävästi'?

(leikata)

Niin monet työkalut toimivat nykyään säiliössä tai virtuaalikoneessa. Se lisää muistin tarvetta.

Hanki niin paljon muistia kuin budjettisi kestää. Luulen kuitenkin, että 64 Gt on nykyään käytännöllinen rajoitus suurimmalle osalle kehitystyötä. Sain äskettäin iMac Pron, jossa on 64 Gt kehitystä varten. Käytän isoa työkalusarjaa. Olen tarkistanut Activity Monitorin ja huomaan, että en ole vielä käyttänyt swap-tiedostoa. Mutta kun kaikki työkalut on ladattu, käytän jossain 32 Gt ja 64 Gt välillä, tyypillisesti 40-50 Gt. Mutta itse asiassa en ole vielä ladannut KAIKKEA kerralla.

Mitä sinun on kysyttävä itseltäsi, on:

- Onko tärkeää, että järjestelmä reagoi rakentamisen aikana?
- Kuinka pitkän rakennussyklin olet valmis sietämään?

Käyttöliittymäkehityksessä sinulla ei tyypillisesti ole 'koontisykliä', eli rakentaa/testaa/toista. Kuinka kauan olet valmis odottamaan saadaksesi selville, että teit yksinkertaisen virheen, jonka korjaaminen kestää muutaman sekunnin? 15 minuuttia? 5 minuuttia? 1 minuutti? 30 sekuntia?

Käännettyä kieltä käyttävässä sovelluskehityksessä sinulla on aina rakennussykli, ja se voi olla merkittävä. Ymmärrän, että Swift-rakennussykli on huomattavasti pidempi kuin Objective-C-koontisykli. (En käytä Swiftiä itse, koska teen hybridikehitystä, ja taustalla oleva alustakoodi on Objective-C:ssä (Java Androidille), C:ssä ja C++:ssa - ei Swiftiä).

Käytettävissä olevan RAM-muistin määrällä on merkittävä vaikutus rakennusjaksoaikaan.

Tämä tiivistää asian melko pitkälle. Jos sinun on käytettävä virtuaalikoneita, 8 Gt on mahdollista (voit käyttää yhtä virtuaalikonetta mukavasti 8 Gt RAM-muistissa). Jos sinulla on SSD, nopeusero 8 Gt:n ja suuremman RAM-muistin välillä ei ole kovin ilmeinen, ellet käytä suurta määrää virtuaalikoneita ja/tai yritä kääntää valtavaa koodikantaa. C

Rakentaa

23. kesäkuuta 2010
  • 17. joulukuuta 2018
Erona 8 Gt:n koneen ja 16 Gt:n koneen välillä on se, että sinun on toisinaan tehtävä tietoisia päätöksiä siitä, mitkä muistinhimoiset sovellukset pitää etualalla.

Muistia vaativat sovellukset, kuten XCode ja Android Studio, käyvät mainiosti 8 Gt:ssa. Ongelma syntyisi, jos yrittäisit käyttää Slackia yhdistettynä useisiin ryhmiin jättäen samalla Chromen auki lukuisilla välilehdillä tai ehkä VM-järjestelmän ajamaan joitain Docker-säilöjä. Samanaikaisuus aiheuttaa ongelmia.

Jos sinulla on varaa hypätä 16 Gt: hen ja aiot pitää tämän koneen jonkin aikaa, mielestäni se on täysin sen arvoista tulevaisuuden turvallisuuden vuoksi. Jos lisäkustannukset riittävät saamaan sinut ajattelemaan kahdesti, unohda se ja tee vain 8 Gt. Tulet olemaan onnellinen joka tapauksessa.
Reaktiot:Nimetön hiiri

revmacian

20. lokakuuta 2018
KÄYTTÖT
  • 17. joulukuuta 2018
jtara sanoi: 8 Gt ei varmasti riitä - esimerkiksi - Mac Minissä, sillä melko hyvä pala (mallista riippuen) siitä käytetään näyttöön.

Kuten aiemmin totesin, käytän Xcodea vuoden 2014 Mac minissäni - siinä on 4 Gt RAM-muistia, enkä näe mitään ongelmia. Jos voin koodata mukavasti 4 Gt:lla, niin 8 Gt riittää. J

jtara

23. huhtikuuta 2009
  • 30. joulukuuta 2018
kadammanali987 sanoi: (Ihmiset säilyttävät usein hakemuksen kääntämistä ja pelaamista varten siihen asti. Tämä hidastaa käsittelyä)

Tai voit vain nopeuttaa käännös-linkki-ajo-sykliä siihen pisteeseen, jossa se kestää vain muutaman minuutin terveellisen nousemisen tuolista.

Yksi osa siitä on, että kääntäjällä on tarpeeksi muistia toimiakseen tehokkaasti, ilman vaihtoa.

Se, että voit, ei tarkoita, että sinun PITÄISI. Sinun on päätettävä, kuinka arvokasta aikasi on.

Tämän yhtälön ratkaiseva hetki minulle oli monia, monia vuosia sitten. Tuote nimeltä Instant-C. Se lyhensi syklin useista minuuteista useisiin sekunteihin. Se inspiroi minua lyhentämään käännös-linkki-ajosykliä sovelluksessa, joka simuloi ja analysoi variaatioita (alunperin Fortranissa kirjoitetusta mallista) mekaanisissa kokoonpanoissa 1/2 tunnista alle minuuttiin. (OK, huijasin - poistin käännös-linkki-ajo-syklin... kirjoittamalla toimialuekohtaisen kääntäjän ja kumppanin tavukooditulkin) 35 vuotta myöhemmin se on edelleen hallitseva ratkaisu kyseiselle toimialueelle.

Joka tapauksessa OP teki päätöksensä - mielestäni viisaan.

BTW, jos käyttäisin edelleen vuoden 2012 i7 Miniäni rakentamiseen, käyttäisin muistilevyä. Se puolittaa minun Minin rakentamisajan. Kokeilin sitä uudessa iMac Prossani, mutta sillä ei ollut samaa vaikutusta. Pelkäänpä, että en ajatellut kokeilla muistilevyä ennen kuin sain iMac Pron. MacOS:lla ei todellakaan ole loistavia RamDisk-ratkaisuja. Minissä on 16 Gt. Ei ole marginaalia muistilevylle koneessa, jossa on 4 Gt. (iMac Prossa on 64 Gt).

vbctv

to
25. syyskuuta 2013
Cleveland, OH
  • 2. toukokuuta 2019
jtara sanoi: Käyttääkö MacBook Pro järjestelmämuistia näytölle?

8 Gt ei varmasti riitä - esimerkiksi - Mac Minissä, sillä aika hyvä osa (mallista riippuen) siitä käytetään näyttöön.

Tärkein tässä annettu palaute on, että viimeaikaisissa MacBookeissa muisti on juotettu alas. Teet päätöksen seuraaville vuosille.

Minulla on 2018 mac Mini, joka on kytketty kahteen näyttöön ja minulla on 8 Gt RAM-muistia, en näe koskaan mitään ongelmia ja teen sekä Android Studion että Xcoden kehitystyötä sekä MAMP Prota taustalla. Muistin painemittari ei koskaan todella nouse ja pysyy aina vihreänä ja matalana. Olen pohtinut 16 Gt:n päivityksestä, mutta en todellakaan näe tarvetta, ellen löydä myytävänä myytävää.... C

ChromeCloud

21. kesäkuuta 2009
Italia
  • 2. toukokuuta 2019
Suurin osa tähän mennessä olevista vastauksista on mielestäni ollut harhaanjohtavia.

Kun yritän käyttää MacBook Airia, jossa on 4 Gt RAM-muistia, iOS-sovellusten kehittämiseen (puhun oikeista sovelluksista, en vain pienistä demoprojekteista), kokemuksesta tulee melko turhauttava erittäin nopeasti. Pelkästään Xcoden ja Safarin avaaminen 3 tai 4 välilehdellä kyllästää RAM-muistisi täysin (muista, että järjestelmä itsessään vie noin 2 Gt) ja simulaattorin käyttäminen sovellusten virheenkorjaukseen on melko mahdotonta (tietokone hidastuu niin, että se ei reagoi).

8 Gt:lla pärjäät. Mutta ei kauaa. Oletetaan, että 8 Gt on minimi, jotta koko iOS-kehityspaketti pyörii mukavasti + pari sovellusta sivussa, jos haluat oman hienon tekstieditorin tai työkalut esimerkiksi vektorigrafiikan tekemiseen.

Joten jos minun pitäisi ostaa uusi kone nyt ja pitää se seuraavat 3 vuotta tai enemmän, saisin vähintään 16 Gt RAM-muistia.

Toinen varoituksen sana: En olisi koskaan odottanut tätä muutama vuosi sitten, kun ostin iMacin (jossa on 32 Gt RAM-muistia ja se on päätyöasemani), mutta näyttää siltä, ​​että jos haluat käyttää simulaattoria ilman koko graafisen käyttöliittymän pätkimistä, VRAM (alias videomuisti) on myös tärkeä rooli yhtälössä.

Retina-iMacille 2 Gt:n näytönohjain ei riitä ajamaan kaikkea sujuvasti: muutaman sekunnin välein puskuri täyttyy (koen tämän kuitenkin vain simulaattoria käytettäessä) ja iMac jäätyy sekunnin murto-osaan. tyhjennetään ja täytetään uudelleen. Se on super ärsyttävää.

Suosittelen siis jotain, jonka parissa voit työskennellä mukavasti seuraavat 3 vuotta: 16 Gt RAM-muistia (tai enemmän) + 4 Gt VRAM (tai enemmän) .
Reaktiot:Emanuel rodriguez M

mkelly

29. marraskuuta 2007
  • 3. toukokuuta 2019
8 Gt riittää tälle päivälle, kunhan et käytä virtuaalikoneita. 16 Gt on luultavasti paras paikka, jos katsot kannettavaa tietokonetta, joka kestää 4-6 vuotta. 32/64 Gt on liikaa, ellet käytä useita virtuaalikoneita samanaikaisesti tai sinulla ei ole rahaa kuluttaa. M

väkijoukkoja

12. helmikuuta 2019
  • 4. toukokuuta 2019
Xcode painaa prosessoria vähemmän RAM-muistia. Ostin juuri Mac mini 2018 i7 6 -ytimisen ja kun käännän iOS:n ja Swiftin Xcodessa, aktiivisuusmonitorin prosessori on 90 %!
Samassa sovelluksessa näen, että RAM-muistin käyttö on alle 8 Gt ilman vaihtoa. Myöhemmin olen ajatellut päivittää RAM-muistia, mutta minulla ei ole kiirettä tällä hetkellä. F

Filipeteixeira

10. huhtikuuta 2013
  • 6. toukokuuta 2019
Sen pitäisi olla enemmän kuin tarpeeksi. Usein se on ongelma vain, kun työskentelet kielten, kuten R tai vastaavan, kanssa. Koska näillä kielillä on usein tapana ladata kaikkea muistiin, mikä tarkoittaa, että suurilla tietojoukoilla on, mitä enemmän RAM-muistia on, sitä paremmin se toimii.