IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

NetBeans Java Discussion :

Mémoire nécessaire pour développer confortablement


Sujet :

NetBeans Java

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre averti
    Inscrit en
    Octobre 2006
    Messages
    17
    Détails du profil
    Informations forums :
    Inscription : Octobre 2006
    Messages : 17
    Par défaut Mémoire nécessaire pour développer confortablement
    Bonjour,

    ce message paraît peut être anodin et peut être déplacé mais en voici sa raison:

    Je développe avec Netbeans actuellement (5.5) sur une machine PIV 2 GHz.
    J'ai 512 MB de RAM (SDRAM 133) et je tourne sous Fedora Core 5 (WindowMaker pour alléger encore plus la charge).
    J'en arrive à cette conclusion:

    - Impossible de travailler avec Netbeans. L'application prend un petit temps à charger mais dès que je veux travailler avec (recherche dans les sources, lancement de nouveaux projets + JBoss ou SunApp y compris module UML) je rame à fond.

    Ok je me dis que l'enterprise Pack est inutile et que je ne m'en servirai que plus tard. Je n'ai donc que l'IDE ---> ça rame encore !

    Que puis-je faire ? Je viens de commander 2 barrettes de RAM (2x 512 Mb de vieille SDRAM Crucial c'est pas donné). J'espère avoir fait le bon choix. Qu'en pensez-vous ?

    Comment faites-vous pour développer avec Netbeans sans que votre PC ne rame ? Avez-vous plus de 512 MB ? Moins peut-être ?

    Merci de vos conseils avisés car là je nage (je rame plutôt).

    Cordialement,


    Charly

  2. #2
    Membre éprouvé
    Avatar de Valère
    Profil pro
    Inscrit en
    Août 2005
    Messages
    1 334
    Détails du profil
    Informations personnelles :
    Âge : 50
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : Août 2005
    Messages : 1 334
    Par défaut
    Quelques conseils pour réduire la voilure:
    • Est ce que tu accèdes à tes fichiers depuis une ressource distante (montage, etc?)
    • As-tu essayé de supprimer le répertoire .netbeans\var\cache\mdrstorage (NB arrété) qui peut, s'il est corrompu, ralentir NB?
    • Tu peux aller fouiner dans Tools|Module Manager pour desactiver des modules qui ne te servent pas.
    • Tu peux aussi accorder davantage de mémoire à ton NB (voir dans ~nbInstallDir/etc/nb.conf).


    NB peut parfaitement tourner en mode basique avec 512Mo sur ta station, mais dès que tu rajouttes des modules/packs, ou si tu travailles avec un serveur applicatif celà peut vite devenir insuffisant. En particulier, j'ai vu quelque part sur le projet UML de NB qu'ils recommandent d'attribuer carrément 512 Mo à NB pour travailler convenablement...

  3. #3
    Membre averti
    Inscrit en
    Octobre 2006
    Messages
    17
    Détails du profil
    Informations forums :
    Inscription : Octobre 2006
    Messages : 17
    Par défaut
    Citation Envoyé par valered
    Quelques conseils pour réduire la voilure:
    • Est ce que tu accèdes à tes fichiers depuis une ressource distante (montage, etc?)
    • As-tu essayé de supprimer le répertoire .netbeans\var\cache\mdrstorage (NB arrété) qui peut, s'il est corrompu, ralentir NB?
    • Tu peux aller fouiner dans Tools|Module Manager pour desactiver des modules qui ne te servent pas.
    • Tu peux aussi accorder davantage de mémoire à ton NB (voir dans ~nbInstallDir/etc/nb.conf).


    NB peut parfaitement tourner en mode basique avec 512Mo sur ta station, mais dès que tu rajouttes des modules/packs, ou si tu travailles avec un serveur applicatif celà peut vite devenir insuffisant. En particulier, j'ai vu quelque part sur le projet UML de NB qu'ils recommandent d'attribuer carrément 512 Mo à NB pour travailler convenablement...
    Merci valered ! Je me disais bien que je ne devais pas être seul dans ce cas.

    Je vais donc essayer de virer le fichier en question "mdrstorage" et allouer de la RAM pour /etc/nb.conf

    Le système lancé sans aucun serveur et aucune ressource pèse dans les 240 Mb (avec seulement WindowMaker). J'ai cru observer une mémoire utilisée par NB de l'ordre de 300 Mb (plutot 250 Mb pour de l'écriture de code).

    Cela nous fait du 500 Mb et des poussières utilisées par mon système (hors swap bien entendu). Je pensais à 1 Gb de RAM pour "commencer" à travailler confortablement. Est-ce pareil chez vous ?

    Un développeur JAVA "moyen" sous NB il travaille avec plus de 512 Mb de RAM ? (un petit sondage serait sympa).


    Charly

  4. #4
    Membre averti
    Inscrit en
    Octobre 2006
    Messages
    17
    Détails du profil
    Informations forums :
    Inscription : Octobre 2006
    Messages : 17
    Par défaut
    Selon http://www.netbeans.org/community/re..._relnotes.html

    Recommended Hardware Configuration

    Microsoft Windows operating systems:
    Processor: 1.4 GHz Intel Pentium III workstation or equivalent
    Memory: 1 GB
    Disk space: 1 GB of free disk space


    Linux operating system:
    Processor: 1.4 GHz Intel Pentium III or equivalent
    Memory: 1 GB
    Disk space: 850 MB of free disk space


    Solaris OS (SPARC®):
    Processor: UltraSPARC IIIi 1 GHz
    Memory: 1 GB
    Disk space: 850 MB of free disk space


    Solaris OS (x86/x64 platform edition):
    Processor: AMD Opteron 100 Series 1.8 GHz
    Memory: 1 GB
    Disk space: 850 MB of free disk space


    Macintosh OS X operating system:
    Processor: PowerPC G5
    Memory: 1 GB
    Disk space: 850 MB of free disk space
    Les recommendations sont bien élevées. Et pourtant elles semblent être justes.


    Charly

  5. #5
    Membre averti
    Inscrit en
    Octobre 2006
    Messages
    17
    Détails du profil
    Informations forums :
    Inscription : Octobre 2006
    Messages : 17
    Par défaut
    Et voici la page du "Tweak"
    http://performance.netbeans.org/howt...hes/index.html
    :


    Tuning JVM switches for performance
    JVMs offer a variety of standard and non-standard switches that tune memory allocation and garbage collection behavior. Some of these settings can benefit NetBeans' performance.

    Note that -X and especially -XX JVM switches are officially "unsupported" - they are often JVM or JVM-vendor specific. The switches discussed on this page are available on Sun Microsystems J2SE 1.5.0 - users of other JVM implementations may need to remove these switches in order to run NetBeans. For example, if you want to run the IDE on IBM JDK, you have to remove -J-XXermsize=32m and –J-XX:MaxPermSize=96m from the configuration file $NB_HOME/etc/netbeans.conf.

    The documentation of Sun's JDK 5 and newer refers to Trouble-Shooting and Diagnostic Guide containing many tips how to find problems that are often related to performance.

    How to specify JVM switches

    Java switches are passed on the command line that starts the JVM, for example, by typing java -jar -Xmx96M someJar.jar. Since NetBeans is started by a launcher program rather than by calling java directly, the NetBeans launcher looks for these settings in a special file called netbeans.conf in etc directory of IDE instalation. Alternatively, arguments can be passed to the java process on the command line by prepending -J to them.
    For example, to set the -Xmx (maximum heap size) for the JVM NetBeans will run in, edit the file called netbeans.conf in the $NB_HOME/etc directory, and include the option -J-Xmx256m or launch the ide by typing


    ./netbeans -J-Xmx256m

    or, on Windows systems

    netbeans.exe -J-Xmx256m
    The netbeans.conf file can have the various JVM switches included in the text string assigned to netbeans_default_options variable. Note that the Sun JVM does not start when passed line switches it doesn't understand, but it will return a message pointing out what the problem was, for example:

    java -foo
    Unrecognized option: -foo
    Could not create the Java virtual machine.


    Generally useful switches

    The following settings should produce better-than-factory setting performance on most systems. With the exception of setting the "permanent area" size, these switches have been the defaults for NetBeans for some time, and should already be in your netbeans.conf file.
    -J-Xverify:none - this switch turns off Java bytecode verification, making classloading faster, and eliminating the need for classes to be loaded during startup solely for the purposes of verification. This switch improves startup time, and there is no reason not to use it.
    -J-Xms32m - this setting tells the Java virtual machine to set its initial heap size to 32 megabytes. By telling the JVM how much memory it should initially allocate for the heap, we save it growing the heap as NetBeans consumes more memory. This switch improves startup time. It is used by default in NetBeans, so you do not need to specify it.
    -J-Xmx256m - this settings tells the Java virtual machine the maximum amount of memory it should use for the heap. Placing a hard upper limit on this number means that the Java process cannot consume more memory than physical RAM available. This limit can be raised on systems with more memory. Current default value is 128MB. Note: Do not set this value to near or greater than the amount of physical RAM in your system or it will cause severe swapping during runtime.

    More exotic switches
    Listed below are some additional JVM switches which have either anecdotally or measurably impacted NetBeans performance on some, not all, systems. Your mileage may vary, but they may be worth a try.


    -J-XX:+UseConcMarkSweepGC or -J-XX:+UseParNewGC - try these switches if you are having problems with intrusive garbage collection pauses. This switch causes the JVM to use different algorithms for major garbage collection events (also for minor collections, if run on a multiprocessor workstation), ones which do not "stop the world" for the entire garbage collection process. You should also add the line -J-XX:+CMSClassUnloadingEnabled and -J-XX:+CMSPermGenSweepingEnabled to your netbeans.conf file so that class unloading is enabled (it isn't by default when using this collector).
    -XX:+UseAdaptiveSizePolicy - this switch may help improve garbage collector throughput and memory footprint. It is part of garbage collector ergonomics implemented in JDK5.0.
    -J-XX:+UseParallelGC - some tests have shown that, at least on systems fairly well equipped with memory, the durations of minor garbage collections is halved when using this collection algorithm, on uniprocessor systems. Note that this is paradoxical - this collector is designed to work best on multiprocessor systems with gigabyte heaps. No data is available on its effect on major garbage collections. Note: this collector is mutually exclusive with -J-XX:+UseConcMarkSweepGC. . The measurements supporting the use of this algorithm can be found on the performance website.
    -J-XX:+PrintGCDetails - this is similar switches (like -J-verbose:gc) do not improve performance but provide diagnostic data showing information about memory management that are useful source of input for performance tuning. Another way how to obtain these data is to use monitoring tools or (NetBeans) profiler.
    -J-XX:CompileThreshold=100 - this switch will make startup time slower, by HotSpot to compile many more methods down to native code sooner than it otherwise would. The reported result is snappier performance once the IDE is running, since more of the UI code will be compiled rather than interpreted. This value represents the number of times a method must be called before it will be compiled.
    -J-Djava.net.preferIPv4Stack=true - this switch will suppress use of IPv6 stack in networking code and it can avoid small delay during startup when inet address is being resolved. It will be usefull only on a system where IPv6 is installed but not actually configured.
    Options affecting graphic behavior
    This document contains only a small subset of switches available. More detailed description about properties affecting Java 2D(TM) behavior can be found in System Properties for Java 2D(TM) Technology document.

    -Dsun.java2d.opengl=true - enables a new OpenGL-based pipeline for Java 2D used to support hardware-accelerated rendering using OpenGL. More details about this new JDK5.0 feature are in Java 2D(TM) Technology documentation.
    -Dsun.java2d.d3d=false - this switch disables DirectDraw and may solve performance problems with some HW configurations.

    -Dawt.nativeDoubleBuffering=true - this switch makes Swing assume the OS is handling double buffering and it shouldn't do any. This will probably not work over a remote X connection, but for local use it's very useful because you literally see every repaint get done, and it makes it very easy to notice if some operation is causing gratuitous repaints.

    Font anti-aliasing for Swing widgets can be turned on with -Dswing.aatext=true property. It can be useful to use together with the setting and exporting of the environment variable J2D_PIXMAPS=shared at least on Linux platform to obtain reasonable performance (this is now done by default in the launcher (platform5/lib/nbexec) so you do not need to set it).
    More exhaustive list of these options can be found at JavaTM HotSpot VM Options page that also refers to another document containing more thorough description of GC tuning.

  6. #6
    Membre averti
    Inscrit en
    Octobre 2006
    Messages
    17
    Détails du profil
    Informations forums :
    Inscription : Octobre 2006
    Messages : 17
    Par défaut
    ........ Et pour une meilleure performance, utiliser
    Mustang !

Discussions similaires

  1. Réponses: 0
    Dernier message: 07/02/2010, 13h18
  2. Quantité de mémoire nécessaire pour une base SQL
    Par mymoi dans le forum Optimisations
    Réponses: 2
    Dernier message: 20/03/2009, 09h54
  3. Réponses: 3
    Dernier message: 25/04/2006, 11h32
  4. Idée pour développer un logiciel de peer to peer
    Par Jibees dans le forum Développement
    Réponses: 5
    Dernier message: 09/06/2003, 22h29

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo