Discussion :

[afrikha]

voilà,je me demandais pourquoi quand on compile deux fois un mème fichier source sans obtenir d'erreurs, la deuxiéme compilation est plus rapide que la première?

[ Modéré par Viena ]
Ajout d'un tag et modification du titre : Pour la compréhension de tous, utilisez un titre clair et les tags ! merci.
Les Règles du Forum

[elitost]

non ( si rien ne perturbe la compilation ).

[afrikha]

non ( si rien ne perturbe la compilation ).

désolé de te contre dire mais si,je viens de refaire l'experience,j'ai eu un temps de compilation à la deuxième fois,dix fois moins long qu'à la première!!, je précise que j'utilise le jdk1.5 de sun.
j'ai cherché des informations sur le fonctionnement de javac mais j'ai rien trouvé.Si quelqu'un pouvait eclairer ma lanterne....

[Scorpyosis]

Si c'est deux complations succesives, ca peut peut-être s'expliquer par le fait que moins de test sont effectués vu qu'aucun changement n'a été éfféctué (hypothèse).

Sinon compilation via un IDE ou en ligne de commande et sous quel OS, parce que ca peut venir de là aussi.

[afrikha]

Si c'est deux complations succesives, ca peut peut-être s'expliquer par le fait que moins de test sont effectués vu qu'aucun changement n'a été éfféctué (hypothèse).

oui,c'est deux compilations successives.Mais le compilateur comment il "sait" qu'aucun changement n'a été éffectué?

Sinon compilation via un IDE ou en ligne de commande et sous quel OS, parce que ca peut venir de là aussi.

alors:compilation en ligne de commande,sous WindowsXp

[Scorpyosis]

Gros fichier java ?

parce que je viens de tester (Xp ligne de commande) avec un petit fichier qui fait 50 lignes environ, et il y a pas de différence notable, en tout cas pas dans un rapport de 10.

[afrikha]

moi j'ai testé avec un tout petit fichier d'une seule classse,faisant une dizaine de lignes.

[Gfx]

Avec un fichier contenant juste class A {} je constate la difference. Je pense que cela vient de l'OS qui met en cache les donnees executables du compilateur.

[afrikha]

je ne comprends pas tout là pourrais-tu ètre plus explicite? ,merci

[FFF]

peut-être tout simplement que javac met en relation la dernière date de modification de ton fichier source avec ton exécutable (via fichier log), si ton fichier source ne change pas alors javac ne fait rien (puisque l'exécutable est déjà crée). il y a peut -être une notion de version derrière tout ça...
Normalement si tu compiles t'effaces ton executable et tu recompiles, il n'y a plus de différence de durée je pense...

Ce ne sont que des supposition logiques..

[bouye]

Je pense que cela vient de l'OS qui met en cache les donnees executables du compilateur.

Plutot que de re-lire le code du compilateur sur le disque a partir du fichier javac.exe et de le charger en memoire pour pouvoir l'executer et ce a chaque utilisation du programme, Windows utiliserai un cache dans lequel ce code est stocke pendant un certain temp. Cela permet donc d'optimiser le lancement de la meme application plusieurs fois successivement ou d'economiser de la memoire quand on en lance plusieurs instances en meme temps.

Plusieurs systemes UNIX fonctionnent de cette maniere egalement. C'est super utile dans des systemes avec plein d'utilisateurs sur un meme serveur pour eviter de se trouver avec plein de duplica du code executable en memoire. Ex a la fac en license on etait sur des Terminaux X et donc en fait les applications tournaient sur un serveur unique (SunOS je crois). Tous les etudiants lancaient Emacs en meme temps. Le code executable d'emacs etait centralise qq part dans un espace memoire unique utilise par tout le monde (de maniere transparente). Ensuite chacun avait sa propre pile et on propre tas d'execution bien a lui.

Ainsi le temps de compilation resterai le meme, seul varierai le temps de chargement du code du compilateur. Ce n'est qu'une supposition bien sur.

[Gfx]

Notez que la date derniere modification du .class change meme si le fichier source n'a pas change. Je doute vraiment que javac recompile tout a chaque fois mais il va quand meme faire quelque chose dans les .class.

[soad]

Je pense que cela vient de l'OS qui met en cache les donnees executables du compilateur.

Plutot que de re-lire le code du compilateur sur le disque a partir du fichier javac.exe et de le charger en memoire pour pouvoir l'executer et ce a chaque utilisation du programme, Windows utiliserai un cache dans lequel ce code est stocke pendant un certain temp. Cela permet donc d'optimiser le lancement de la meme application plusieurs fois successivement ou d'economiser de la memoire quand on en lance plusieurs instances en meme temps.

Plusieurs systemes UNIX fonctionnent de cette maniere egalement. C'est super utile dans des systemes avec plein d'utilisateurs sur un meme serveur pour eviter de se trouver avec plein de duplica du code executable en memoire. Ex a la fac en license on etait sur des Terminaux X et donc en fait les applications tournaient sur un serveur unique (SunOS je crois). Tous les etudiants lancaient Emacs en meme temps. Le code executable d'emacs etait centralise qq part dans un espace memoire unique utilise par tout le monde (de maniere transparente). Ensuite chacun avait sa propre pile et on propre tas d'execution bien a lui.

Ainsi le temps de compilation resterai le meme, seul varierai le temps de chargement du code du compilateur. Ce n'est qu'une supposition bien sur.

je confirme !!!

et seule la première compilation est la plus lente, si tu compile 2, 3, 4, 5 , ... fois la vitesse reste la meme !!! (A moins que la mémoire cache c'est vider pour un autre chose)

tu peux aussi essayer d'ouvrir l'explorer, word, ou n'importe quel autre programme, la 1er fois sera tjs la plus lente