iMacédonien
Affiche originale- 10 octobre 2015
- Brno, CZ
- 15 déc. 2018
J'envisage sérieusement d'acheter un MacBook Pro 13 '2018. L'utilisation principale de l'ordinateur portable serait le codage (développement Web frontal), mais j'aimerais me plonger plus tard dans le développement d'applications iOS. Cela dit, 8 Go de RAM suffisent-ils pour exécuter XCODE ou devrais-je investir davantage pour obtenir la version 16 Go ?
revmacien
- 20 octobre 2018
- LES USAGES
- 15 déc. 2018
iMacedonian a dit : Salut.J'exécute Xcode sur mon Mac mini 2014 - il a 4 Go de RAM et je ne vois aucun problème. Il y aura des gens qui vous diront que 16 Go ou plus de RAM sont indispensables, mais j'ai vu que ce n'est tout simplement pas vrai.
J'envisage sérieusement d'acheter un MacBook Pro 13 '2018. L'utilisation principale de l'ordinateur portable serait le codage (développement Web frontal), mais j'aimerais me plonger plus tard dans le développement d'applications iOS. Cela dit, 8 Go de RAM suffisent-ils pour exécuter XCODE ou devrais-je investir davantage pour obtenir la version 16 Go ?
Emmanuel Rodriguez
- 17 octobre 2018
- 15 déc. 2018
revmacian a dit : J'exécute Xcode sur mon Mac mini 2014 - il a 4 Go de RAM et je ne vois aucun problème. Il y aura des gens qui vous diront que 16 Go ou plus de RAM sont indispensables, mais j'ai vu que ce n'est tout simplement pas vrai.D'accord. J'ai découvert que même un Raspberry Pi avec son seul Go de RAM est capable de compiler la plupart des choses. Si un projet a une tonne de code C++ (en vous regardant LLVM), ou d'autres langages complexes (nécessitant que le compilateur travaille dur, et utilise donc plus de RAM), alors il ne peut généralement pas le gérer. Il semble qu'environ 3 Go soit un minimum sûr pour le travail de développement, d'après mon expérience.
EDIT : gardez à l'esprit qu'il s'agissait de 3 Go à l'intérieur d'une machine virtuelle, sans interface graphique. L'option 8 Go est définitivement sûre, pour l'instant. Je recommanderais 16 Go juste pour la pérennité. 8 Go commence à devenir moins confortable que par le passé. Dernière édition : 15 décembre 2018
ammuler
- 18 déc. 2015
- 16 déc. 2018
doglobber
- 19 octobre 2014
- Campus Apple, Cupertino CA
- 16 déc. 2018
960design
- 17 avr. 2012
- Destin, FL
- 17 déc. 2018
iMacedonian a dit : Salut.8 Go, c'est beaucoup, j'utilise un MBPr de 16 Go et je vois rarement la pression de la mémoire dépasser les 8 Go.
J'envisage sérieusement d'acheter un MacBook Pro 13 '2018. L'utilisation principale de l'ordinateur portable serait le codage (développement Web frontal), mais j'aimerais me plonger plus tard dans le développement d'applications iOS. Cela dit, 8 Go de RAM suffisent-ils pour exécuter XCODE ou devrais-je investir davantage pour obtenir la version 16 Go ?
En passant, vérifiez dans Expo.io ( https://expo.io/ ). C'est ce que tous les enfants cool utilisent de nos jours (beaucoup plus facile à déployer sur plusieurs plates-formes). Mise en garde : fonctionnera pour la plupart des applications, mais certaines ont des exigences matérielles / besoins spécifiques que expo ne répondra pas. Néanmoins un point de départ fantastique.
jtara
- 23 avr. 2009
- 17 déc. 2018
Voulez-vous dire « assez pour que les builds n'échouent pas ? »
Ou « assez pour que la construction soit terminée dans un délai acceptable » ?
Et/ou « assez pour que l'interface utilisateur ne soit pas lente et que je puisse travailler dans un éditeur/naviguer sur le Web/lire les e-mails pendant une construction sans lenteur ?
Cela dépend de vos attentes et de votre outillage.
Le développement frontal a généralement une chaîne d'outils courte/simple. Tout ce dont vous avez vraiment besoin est un bon éditeur adapté à la tâche, un petit serveur Web « jouet », peut-être des outils pour réduire Javascript/CSS (et peut-être un compilateur Sass) pour les versions de production, et pendant le développement, vous n'utiliseriez généralement même pas cette.
Le développement back-end peut souvent ne nécessiter que le développement front-end. Ou peut-être besoin d'un peu plus. Par exemple, j'utilise PostgreSQL comme base de données. J'ai donc une instance locale pour le développement/test. J'exécute pgAdmin4, qui s'exécute dans un conteneur Docker. Vous devrez peut-être exécuter une machine virtuelle qui réplique votre environnement principal. Les Go s'additionnent.
Le développement d'applications natives se fait souvent avec un minimum d'outils. Pour le développement d'applications iOS de base, vous n'avez besoin que de Xcode. OK, et le simulateur iOS. Si vous effectuez une sorte de développement hybride et multiplateforme, ajoutez probablement des composants de chaîne d'outils supplémentaires - et, par conséquent, des SDK Android et des outils de création. Le développement Android utilise un compilateur différent. Ajoutez un autre simulateur. (J'utilise GenyMotion, car les deux approches fournies par Google sont lentes comme de la mélasse.) Tout simulateur Android décent s'exécute dans une machine virtuelle.
Oh, besoin de tester ce site Web sur Windows ? Ajoutez une machine virtuelle Windows.
Autant d'outils aujourd'hui exécutés dans un conteneur ou une machine virtuelle. Cela ajoute à l'exigence de mémoire.
Obtenez autant de mémoire que votre budget peut en supporter. Je pense, cependant, que 64 Go est la limite pratique aujourd'hui pour la plupart des développements. J'ai récemment eu un iMac Pro avec 64 Go pour le développement. J'utilise un gros ensemble d'outils. J'ai vérifié Activity Monitor et je constate que je n'ai pas encore utilisé de fichier d'échange. Mais une fois tous les outils chargés, j'utilise quelque part entre 32 Go et 64 Go, généralement 40-50 Go. Mais en fait, je n'ai pas encore TOUT chargé en même temps.
Ce que tu dois te demander c'est :
- Est-il important que le système soit réactif lors de la construction ?
- Combien de temps de cycle de construction êtes-vous prêt à tolérer ?
Dans le développement frontal, vous n'avez généralement pas de « cycle de génération », c'est-à-dire génération/test/répétition. Combien de temps êtes-vous prêt à attendre pour découvrir que vous avez fait une simple erreur qui prendra quelques secondes à corriger ? 15 minutes? 5 minutes? 1 minute? 30 secondes?
Dans le développement d'applications utilisant un langage compilé, vous avez toujours un cycle de construction, et cela peut être important. Je comprends que le cycle de construction Swift est sensiblement plus long que le cycle de construction Objective-C. (Je n'utilise pas Swift moi-même, car je fais du développement hybride et le code de la plate-forme sous-jacente est en Objective-C (Java pour Android), C et C++ - pas de Swift).
La quantité de RAM disponible aura un impact significatif sur la durée du cycle de construction.
mpe
- 3 sept. 2010
- 17 déc. 2018
Oui. 8 Go de RAM suffisent pour la plupart des choses.
jtara
- 23 avr. 2009
- 17 déc. 2018
mpe a dit : Oui. 8 Go de RAM suffisent pour la plupart des choses.
Le MacBook Pro utilise-t-il la mémoire système pour l'affichage ?
8 Go ne suffisent sûrement pas sur - par exemple - un Mac Mini, car une assez bonne partie (selon le modèle) est utilisée pour l'affichage.
Le retour le plus important donné ici est que sur les MacBook récents, la mémoire est soudée. Vous prenez une décision pour les prochaines années.
Toutou
à
- 6 janvier 2015
- Prague, République Tchèque
- 17 déc. 2018
iMacédonien
Affiche originale- 10 octobre 2015
- Brno, CZ
- 17 déc. 2018
jtara a dit : Définissez ce que vous entendez par « assez » ?Merci pour cette réponse détaillée, cela m'a donné une meilleure perspective sur les ressources nécessaires pour ces différents scénarios de codage que vous avez mentionnés.
Voulez-vous dire « assez pour que les builds n'échouent pas ? »
Ou « assez pour que la construction soit terminée dans un délai acceptable » ?
Et/ou « assez pour que l'interface utilisateur ne soit pas lente et que je puisse travailler dans un éditeur/naviguer sur le Web/lire les e-mails pendant une construction sans lenteur ?
Cela dépend de vos attentes et de votre outillage.
Le développement frontal a généralement une chaîne d'outils courte/simple. Tout ce dont vous avez vraiment besoin est un bon éditeur adapté à la tâche, un petit serveur Web « jouet », peut-être des outils pour réduire Javascript/CSS (et peut-être un compilateur Sass) pour les versions de production, et pendant le développement, vous n'utiliseriez généralement même pas cette.
Le développement back-end peut souvent ne nécessiter que le développement front-end. Ou peut-être besoin d'un peu plus. Par exemple, j'utilise PostgreSQL comme base de données. J'ai donc une instance locale pour le développement/test. J'exécute pgAdmin4, qui s'exécute dans un conteneur Docker. Vous devrez peut-être exécuter une machine virtuelle qui réplique votre environnement principal. Les Go s'additionnent.
Le développement d'applications natives se fait souvent avec un minimum d'outils. Pour le développement d'applications iOS de base, vous n'avez besoin que de Xcode. OK, et le simulateur iOS. Si vous effectuez une sorte de développement hybride et multiplateforme, ajoutez probablement des composants de chaîne d'outils supplémentaires - et, par conséquent, des SDK Android et des outils de création. Le développement Android utilise un compilateur différent. Ajoutez un autre simulateur. (J'utilise GenyMotion, car les deux approches fournies par Google sont lentes comme de la mélasse.) Tout simulateur Android décent s'exécute dans une machine virtuelle.
Oh, besoin de tester ce site Web sur Windows ? Ajoutez une machine virtuelle Windows.
Autant d'outils aujourd'hui exécutés dans un conteneur ou une machine virtuelle. Cela ajoute à l'exigence de mémoire.
Obtenez autant de mémoire que votre budget peut en supporter. Je pense, cependant, que 64 Go est la limite pratique aujourd'hui pour la plupart des développements. J'ai récemment eu un iMac Pro avec 64 Go pour le développement. J'utilise un gros ensemble d'outils. J'ai vérifié Activity Monitor et je constate que je n'ai pas encore utilisé de fichier d'échange. Mais une fois tous les outils chargés, j'utilise quelque part entre 32 Go et 64 Go, généralement 40-50 Go. Mais en fait, je n'ai pas encore TOUT chargé en même temps.
Ce que tu dois te demander c'est :
- Est-il important que le système soit réactif lors de la construction ?
- Combien de temps de cycle de construction êtes-vous prêt à tolérer ?
Dans le développement frontal, vous n'avez généralement pas de « cycle de génération », c'est-à-dire génération/test/répétition. Combien de temps êtes-vous prêt à attendre pour découvrir que vous avez fait une simple erreur qui prendra quelques secondes à corriger ? 15 minutes? 5 minutes? 1 minute? 30 secondes?
Dans le développement d'applications utilisant un langage compilé, vous avez toujours un cycle de construction, et cela peut être important. Je comprends que le cycle de construction Swift est sensiblement plus long que le cycle de construction Objective-C. (Je n'utilise pas Swift moi-même, car je fais du développement hybride et le code de la plate-forme sous-jacente est en Objective-C (Java pour Android), C et C++ - pas de Swift).
La quantité de RAM disponible aura un impact significatif sur la durée du cycle de construction.
[doublepost=1545084766][/doublepost]
ammulder a dit : Combien de temps prévoyez-vous de garder la machine ? Étant donné que la mémoire ne peut pas être mise à niveau, vous achetez vraiment pour la quantité de mémoire dont vous aurez besoin dans 3 à 5 ans, pas aujourd'hui. (En gardant à l'esprit que chaque version d'outils de développement utilise plus de mémoire que la précédente.) En particulier si vous utilisez des conteneurs ou des machines virtuelles (par exemple pour exécuter une version locale d'un back-end auquel votre application se connecte), la productivité atteint trop peu de mémoire plus tard ne vaut pas les économies de coûts maintenant.Mes ordinateurs portables durent généralement de 4 à 6 ans, voire plus, donc d'après ce que j'ai lu jusqu'à présent, il serait peut-être préférable d'obtenir la version 16 Go si je veux maximiser l'utilisation. À
Anonyme-souris
- 25 août 2016
- 17 déc. 2018
jtara a dit : Définissez ce que vous entendez par « assez » ?
(couper)
Autant d'outils aujourd'hui exécutés dans un conteneur ou une machine virtuelle. Cela ajoute à l'exigence de mémoire.
Obtenez autant de mémoire que votre budget peut en supporter. Je pense, cependant, que 64 Go est la limite pratique aujourd'hui pour la plupart des développements. J'ai récemment eu un iMac Pro avec 64 Go pour le développement. J'utilise un gros ensemble d'outils. J'ai vérifié Activity Monitor et je constate que je n'ai pas encore utilisé de fichier d'échange. Mais une fois tous les outils chargés, j'utilise quelque part entre 32 Go et 64 Go, généralement 40-50 Go. Mais en fait, je n'ai pas encore TOUT chargé en même temps.
Ce que tu dois te demander c'est :
- Est-il important que le système soit réactif lors de la construction ?
- Combien de temps de cycle de construction êtes-vous prêt à tolérer ?
Dans le développement frontal, vous n'avez généralement pas de « cycle de génération », c'est-à-dire génération/test/répétition. Combien de temps êtes-vous prêt à attendre pour découvrir que vous avez fait une simple erreur qui prendra quelques secondes à corriger ? 15 minutes? 5 minutes? 1 minute? 30 secondes?
Dans le développement d'applications utilisant un langage compilé, vous avez toujours un cycle de construction, et cela peut être important. Je comprends que le cycle de construction Swift est sensiblement plus long que le cycle de construction Objective-C. (Je n'utilise pas Swift moi-même, car je fais du développement hybride et le code de la plate-forme sous-jacente est en Objective-C (Java pour Android), C et C++ - pas de Swift).
La quantité de RAM disponible aura un impact significatif sur la durée du cycle de construction.
Cela résume à peu près tout. Si vous avez besoin d'exécuter des machines virtuelles, alors 8 Go est faisable (vous pouvez exécuter une machine virtuelle confortablement dans 8 Go de RAM). Si vous avez un SSD, la différence de vitesse entre avoir 8 Go et plus de RAM ne sera pas très évidente, sauf si vous exécutez un grand nombre de machines virtuelles et/ou essayez de compiler une énorme base de code. C
Construction
- 23 juin 2010
- 17 déc. 2018
Les applications gourmandes en mémoire comme XCode et Android Studio feront très bien l'affaire avec 8 Go. Le problème surviendrait si vous essayiez d'exécuter Slack connecté à plusieurs groupes, tout en laissant Chrome ouvert avec de nombreux onglets, ou peut-être un système VM pour exécuter certains conteneurs Docker. C'est la simultanéité qui cause les problèmes.
Si vous pouvez vous permettre de passer à 16 Go et que vous prévoyez de conserver cette machine pendant un certain temps, je pense que cela en vaut la peine pour la pérennité. Si le coût supplémentaire est suffisant pour vous faire réfléchir à deux fois, alors oubliez-le et faites simplement 8 Go. Vous serez heureux de toute façon.
revmacien
- 20 octobre 2018
- LES USAGES
- 17 déc. 2018
jtara a dit : 8 Go ne suffisent sûrement pas sur - par exemple - un Mac Mini, car une assez bonne partie (selon le modèle) est utilisée pour l'affichage.
Comme je l'ai dit plus tôt, j'exécute Xcode sur mon Mac mini 2014 - il dispose de 4 Go de RAM et je ne vois aucun problème. Si je peux coder confortablement avec 4 Go, alors 8 Go suffisent. J
jtara
- 23 avr. 2009
- 30 déc. 2018
kadammanali987 a déclaré : (Les gens gardent souvent l'application pour compiler et jouer à des jeux jusqu'à ce moment-là. Cela ralentit le traitement)
Ou vous pouvez simplement accélérer le cycle de compilation-liaison-exécution au point où il ne faut pas plus que quelques minutes pour sortir vos fesses de la chaise.
Une partie de cela est d'avoir suffisamment de mémoire pour que le compilateur fonctionne efficacement, avec un minimum/aucun échange.
Que vous POUVEZ ne signifie pas que vous DEVRIEZ. Vous devez décider à quel point votre temps est précieux.
Le moment déterminant pour cette équation pour moi était il y a de nombreuses années. Un produit appelé Instant-C. Il a réduit ce cycle de quelques minutes à plusieurs secondes. Cela m'a inspiré pour réduire un cycle de compilation-lien-exécution pour une application qui simule et analyse les variations (à partir d'un modèle, écrit à l'origine en Fortran) dans les assemblages mécaniques d'une demi-heure à moins d'une minute. (OK, j'ai triché - j'ai supprimé le cycle compilation-lien-exécution... en écrivant un compilateur spécifique au domaine et un interpréteur de bytecode compagnon) 35 ans plus tard, c'est toujours la solution prédominante pour ce domaine.
Quoi qu'il en soit, OP a pris sa décision - je pense qu'elle est sage.
BTW, si j'utilisais toujours mon i7 Mini 2012 pour les builds, j'utiliserais un Ramdisk. Cela réduit environ de moitié le temps de construction pour moi sur la Mini. Je l'ai essayé sur mon nouvel iMac Pro, mais n'a pas eu le même impact. Je crains de ne pas avoir pensé à essayer le disque virtuel avant d'avoir l'iMac Pro. MacOS n'a pas vraiment d'excellentes solutions RamDisk. La Mini dispose de 16 Go. Il n'y a pas de marge pour un disque virtuel sur une machine de 4 Go. (L'iMac Pro a 64 Go).
vbctv
à
- 25 sept. 2013
- Cleveland, Ohio
- 2 mai 2019
jtara a dit : MacBook Pro utilise-t-il la mémoire système pour l'affichage ?
8 Go ne suffisent certainement pas sur - par exemple - un Mac Mini, car une assez bonne partie (selon le modèle) est utilisée pour l'affichage.
Le retour le plus important donné ici est que sur les MacBook récents, la mémoire est soudée. Vous prenez une décision pour les prochaines années.
J'ai un mac Mini 2018 connecté à 2 moniteurs et j'ai 8 Go de RAM, je ne vois jamais de problèmes et je fais à la fois le travail de développement Android Studio et Xcode et j'exécute MAMP Pro en arrière-plan. Le moniteur de pression à mémoire ne monte jamais vraiment et reste toujours vert et bas. J'ai débattu d'une mise à niveau vers 16 Go, mais je n'en vois pas vraiment le besoin à moins de trouver une offre exceptionnelle en vente... C
ChromeCloud
- 21 juin 2009
- Italie
- 2 mai 2019
Lorsque j'essaie d'utiliser mon MacBook Air avec 4 Go de RAM pour développer des applications iOS (je parle de vraies applications, pas seulement de petits projets de démonstration), l'expérience devient très vite frustrante. Le simple fait d'ouvrir Xcode et Safari avec 3 ou 4 onglets saturera complètement votre RAM (rappelez-vous que le système à lui seul prend environ 2 Go) et il est pratiquement impossible d'utiliser le simulateur pour déboguer vos applications (l'ordinateur ralentit au point de ne plus répondre).
Avec 8 Go, tout ira bien. Mais pas pour longtemps. Disons que 8 Go est le minimum pour exécuter confortablement la suite de développement iOS complète + quelques applications sur le côté si vous voulez avoir un éditeur de texte sophistiqué ou des outils pour créer des graphiques vectoriels par exemple.
Donc, si je devais acheter une nouvelle machine maintenant et la garder pour les 3 prochaines années ou plus, j'obtiendrais au moins 16 Go de RAM.
Un autre mot d'avertissement : je n'aurais jamais prévu cela il y a quelques années lorsque j'ai acheté mon iMac (qui a 32 Go de RAM et c'est mon poste de travail principal), mais il semble que si vous voulez exécuter le simulateur sans tout le bégaiement de l'interface graphique, La VRAM (ou mémoire vidéo) joue également un rôle important dans l'équation.
Pour un iMac Retina, une carte vidéo de 2 Go ne suffira pas à tout faire fonctionner correctement : toutes les quelques secondes, le tampon se remplit (je ne le constate qu'en exécutant le simulateur) et l'iMac se bloque pendant une fraction de seconde pendant qu'il se vide et se remplit à nouveau. C'est hyper énervant.
Ma recommandation pour quelque chose sur lequel vous pouvez travailler confortablement pour les 3 prochaines années est : 16 Go de RAM (ou plus) + 4 Go de VRAM (ou plus) .
mkelly
- 29 novembre 2007
- 3 mai 2019
foules
- 12 févr. 2019
- 4 mai 2019
Dans la même application, je peux voir que l'utilisation de la RAM est inférieure à 8 Go sans swap. Pour plus tard, je pense mettre à jour la RAM mais je ne suis pas pressé pour le moment. F
Filipeteixeira
- 10 avr. 2013
- 6 mai 2019
Articles Populaires