Developpez Magazine Edition de Juin-Juillet 2007. Numéro 10. Magazine en ligne
Developpez Magazine Edition de Juin-Juillet 2007. Numéro 10. Magazine en ligne gratuit. Diffusion de copies conformes à l’original autorisée. Réalisation : Baptiste Wicht Rédaction : la rédaction de Developpez Contact : magazine@redaction-developpez.com Numéro 10 – Juin-Juillet 2007 Developpez Magazine est une publication de developpez.com Page 1 Article Dotnet Utilisez l'effet Glass de Vista Windows Vista et ses fenêtres transparentes vous fait rêver ? Apprenez à utiliser le thème Aero Glass de Windows Vista pour que vous puissiez, vous aussi, avoir de la transparence dans vos fenêtres Winform. par Florian Casabiance Page 17 Article Mac Decouvrez QuartzComposer Certains développeurs excellent dans l'art de réaliser des effets graphiques impressionnants. Apple a pensé à tous les autres en livrant QuartzComposer avec Tiger, la dernière version de MacOS X. par Romain Guy Page 56 Index Java Page 2 Linux/BSD/Unix Page 8 Développement Web Page 11 DotNet Page 16 C & C++ Page 22 SGBD Page 27 Windows Page 33 Mac Page 37 Ruby Page 42 Conception Page 48 2D/3D/Jeux Page 52 Sécurité Page 57 Liens Page 60 Editorial Le 10ème magazine de Developpez.com est arrivé. Retrouvez les nouveaux tutoriaux et ressources des rubriques de Developpez.com. Merci de votre fidelité ! N'hésitez pas à passer sur les forums pour donner votre avis ou faire des suggestions pour cette publication La rédaction Java Les derniers tutoriels et articles L'API java.nio du JDK 1.4 De nombreux programmeurs critiquent Java pour des raisons de performances. Malgré les améliorations constantes de nos ordinateurs et des JVM, ce reproche perdure. Nous allons cependant voir que connaître les API suffit largement pour obtenir d'excellentes performances. 1. Introduction Aujourd'hui, les solutions pour accélérer un programme écrit en Java ne sont pas nombreuses. Nous pouvons changer de processeur pour un plus performant, utiliser l'une des dernières machines virtuelles ou compiler le code source en mode natif. Mais tout ceci se révèle bien souvent superflu. Prenons l'exemple des deux codes source populate1.java et populate2.java. Ceux-ci créent une chaîne de caractères contenant 10 000 entiers tirés au hasard. La première implémentation utilise un objet String et demande 39 secondes d'exécution sur un Pentium IV 1.6 Ghz nanti de 256 Mo de DDRAM. La seconde quant à elle, sur la même configuration, ne requière que 0.03 secondes. Le secret réside dans l'emploi de la classe StringBuffer, plus appropriée. 2. Opérations de lecture L'exemple présenté ci-dessus s'avère particulièrement probant. Sachez qu'il en va de même pour de nombreux types d'opérations et notamment les opérations de lecture de fichiers. Depuis les premières versions du JDK, les classes de support des entrées/sorties résidaient dans le paquetage java.io. Avec l'apparition du JDK 1.4 est né le paquetage java.nio, acronyme signifiant "New Input/Output". Le rôle principal de ce paquetage consiste à améliorer les performances du vieillissant java.io ainsi que d'apporter de nouvelles fonctionnalités telles que le verrouillage des fichiers. Les performances peuvent augmenter considérablement si l'on emploie cette nouvelle API. Néanmoins, nul n'est besoin de l'utiliser constamment. Pour déterminer si une application nécessite une optimisation de ses opérations de lecture ou d'écriture, nous pouvons faire appel à une option de la machine virtuelle qui réalise une trace de notre programme. Le fichier source SourceCodeLinesCounter0.java contient un programme parcourant récursivement l'intégralité des fichiers portant l'extension .java présents dans le répertoire courant et affichant le nombre de lignes total. L'exécution de notre outil sur les sources du JDK 1.4 nécessite 111 secondes. Que pouvons-nous faire pour améliorer ceci ? Exécutons tout d'abord l'option de trace : java -Xrunhprof:cpu=sample,depth=15,file=prof0.txt SourceCodeLinesCounter0 Cette commande génère un fichier nommé prof0.txt dans lequel nous pouvons lire les lignes suivantes : 1 87.76% 87.76% 724 19 java.io.FileInputStream.read 2 5.45% 93.21% 45 20 java.io.FileInputStream.open Ceci signifie que 87% du temps d'exécution est alloué à l'exécution de la méthode read() de la classe FileInputStream. Nous allons tâcher d'optimiser les performances à cet endroit. En parcourant le contenu de java.io, nous découvrons la présence de la classe BufferedReader censée accélérer les opérations de lecture. Le code source SourceCodeLinesCounter1.java emploie cette dernière. Le temps d'exécution tombe alors à 13 secondes. Pouvons-nous faire mieux ? Avec les API antérieures au JDK 1.4, non, à moins d'invoquer la méthode readLine() plutôt que de faire un parcours caractère par caractère. 3. Les nouvelles classes La nouvelle API met à disposition quatre nouvelles familles de classes : les Buffer, séquences linéaires de données, les Charset, faisant la transition entre caractères Unicode et séquences d'octets, les Channels, qui représente des tuyaux de communication bi-directionnels et enfin les Selector, employés pour des opérations d'E/S asynchrones sur des threads. Cette API introduit notamment la notion d'opérations de lecture et d'écriture non bloquantes. Nous ne nous préoccuperons ce mois-ci que des Buffer et Channel. La classe MappedByteBuffer sert à créer une représentation complète d'un fichier en mémoire. De ce fait, son emploi autorise au système à procéder à des optimisations importantes et les temps d'accès s'en trouvent amoindris. Le fichier source SourceCodeLinesCounter2 fait appel à cette classe. Voici un exemple de son utilisation : in = new FileInputStream("fichier").getChannel(); int size = (int) in.size(); bytes = in.map(FileChannel.MapMode.READ_ONLY, 0, size); char c = (char) bytes.get(); Les Buffer de l'API NIO nécessitent de créer un nouveau Channel que nous obtenons grâce à une instance de FileInputStream. La méthode map() des canaux autorise le mappage en mémoire d'une portion définie d'un fichier, ici la totalité. Cette implémentation diminue encore le temps d'exécution de notre programme pour le porter à 10 secondes. Les Buffer possèdent des propriétés très intéressantes principalement en ce qui concerne le positionnement du pointeur de lecture/écriture. Nous pouvons aisément définir ou récupérer sa position courante. Un Buffer possède une capacité maximale et une limite de remplissage. Nous pouvons par exemple écrire 10 octets dans un buffer d'une capacité de 512 octets. Sa limite sera alors 10 octets. Trois méthodes se révèlent utiles : clear(), flip() et rewind(). La dernière replace le pointeur de lecture en début de séquence. La seconde place la limite sur la position courante et renvoie le pointeur en début de séquence. Enfin, Numéro 10 – Juin-Juillet 2007 Developpez Magazine est une publication de developpez.com Page 2 clear() renvoie le pointeur au début et place la limite en fin de séquence. Ces notions de position se veulent extrêmement importantes puisque chaque action de lecture (par l'entremise des méthodes get()) ou d'écriture (par l'intermédiaire des méthodes put()) fait avance le pointeur. 4. Buffer directs et indirects Outre le tampon de mappage en mémoire, le nouveau paquetage propose des tampons directs ou indirects comme par exemple ByteBuffer ou FloatBuffer. Lorsque le développeur utilise un tampon direct, la machine virtuelle s'efforce de réaliser des opérations d'E/S natives directement dessus, sans passer par un tampon intermédiaire, spécifique à la JVM. Malgré leur rapidité d'exécution en règle générale, leur utilisation ne se justifie que dans le cas de manipulation de gros fichiers. En effet, le ramasse-miettes peut éprouver des difficultés à nettoyer ces objets et leur prolifération est vivement déconseillée. La création d'un tampon direct se révèle simple : ByteBuffer bytes = ByteBuffer.allocateDirect(1024); FileChannel in = new FileInputStream("fichier").getChannel(); int read = in.read(bytes); char c = (char) bytes.get(); Pour créer un tampon indirect, il suffit d'appeler la méthode allocate() à la place de allocateDirect(). Ceux-ci font moins appel à des opérations purement natives du système. Toujours dans l'exemple de notre utilitaire de comptage de lignes, nous constatons que les tampons de type direct diminuent un petit peu les performances au regard de celles obtenues par le MappedByteBuffer. Le temps d'exécution est alors de 11 secondes. Enfin, les tampons indirects donnent un temps équivalent à celui obtenu lors de l'emploi d'un BufferedReader, soit 13 secondes. Ces divers tests montrent bien que l'optimisation d'un programme écrit en Java ne demande pas nécessairement de grands efforts. La nouvelle API NIO du JDK 1.4, réellement simple d'emploi, autorise des gains de performances non négligeables et ce pour un coût de développement quasiment nul. Ne vous fiez donc plus aux personnes clamant que Java souffre de lenteur mais apprenez-leur plutôt à utiliser correctement son API. Retrouvez l'article en ligne de Romain Guy : Lien1 Inversion de contrôle en Java Depuis l'avènement de la programmation orientée objet, les développeurs imaginent et implémentent des composants logiciels réutilisables. Les différentes techniques employées jusqu'à aujourd'hui ne sont malheureusement pas toujours parfaites. 1. Introduction L'univers Java voit souvent apparaître de nouvelles technologies favorisant la conception d'architectures logicielles. Depuis quelques années, de nombreux développeurs s'intéressent à l'inversion de contrôle, ou IoC pour Inversion of Control. L'inversion de contrôle figure une nouvelle approche de la programmation de services et de composants. Pour utiliser cette technique, vous devez avoir recours à un conteneur d'inversion de contrôle comme Hivemind, PicoContainer ou Spring. Un conteneur d'IoC peut être identifié par trois caractéristiques majeures : il contient des objets, il contrôle la création de ces objets et il résout les dépendances entre les objets. De par sa nature le conteneur gère le cycle de vie de ces objets. Vous n'avez pas à créer les instances ni à libérer les ressources. Avant de nous intéresser à des exemples d'utilisation de ces conteneurs, uploads/Litterature/ dev-mag-200706.pdf
Documents similaires
-
23
-
0
-
0
Licence et utilisation
Gratuit pour un usage personnel Attribution requise- Détails
- Publié le Jui 23, 2021
- Catégorie Literature / Litté...
- Langue French
- Taille du fichier 1.1361MB