Le 16 août 2014 12:07, Christophe Merlet <red...@redfoxcenter.org> a écrit :
> Le 16/08/2014 11:55, Philippe Verdy a écrit : > > Je n'ai strictement aucun problème avec Java7 que j'utilisse depuis > > longtemps pour JOSM sous Win7. > > > > Cependant je ne l'utilise PAS en version 32bits mais 64bits. le > > compilateur Hotspot ClientVM Java7 32 bits est une vraie daube. Je > > n'utilise QUE la version serveur qui est très stable, très rapide; ne > > swappe pas à répétition. > > > > La version 32 bits a été "optimisée" pour des installations sur de très > > petits appareils mais n'est définitivement plsu faire pour une appli > > comme JOSM qui traite un grand volume de données en mémoire (il est > > courant que j'ai plusieurs millions d'objets chargés, impossible de > > Plusieurs millions d'objets chargés ??? Rien que ça !! > Pas en permanence, j'ai dit "couramment"). Mais en moyenne c'est souvent plus de 400 000 objets et de toute façon des millions de tags. Et la taille de VM est en permanence au dessus de 500Mo (donc déjà au delà des 256Mo de la version 32 bits). Pour la plus petite modif en cours j'ai par exemple (en appuyant sur "cfgm" dans la console: ---------------------------------------------------- Java Web Start 11.5.2.13 Utilisation de la version JRE 1.8.0_05-b13 Java HotSpot(TM) 64-Bit Server VM Répertoire de base de l'utilisateur = C:\Users\Philippe Finaliser les objets de la file d'attente de finalisation ... terminé. Mémoire : 685 056 ko ; disponible : 427 411 ko ; (62 %) ... terminé. Nettoyer la mémoire ... terminé. Mémoire : 696 320 ko ; disponible : 591 649 ko ; (84 %) ... terminé. ---------------------------------------------------- > Tu peux nous faire une capture d'écran de JOSM avec la petite fenêtre > d'informations du calque ? > Je demande à voir ! > > Et n'hésite pas a nous expliquer pourquoi tu dois bosser avec des > volumes de données aussi gigantesque à la fois... et aussi comment tu > fais pour tenir à jour ces données. Je les garde en cache pour retrouver plus facilement les objets et ne pas en oublier (et éviter aussi de créer des doublons). Cela n'empêche pas de mettre à jour sur la sélection et de mettre à jour très souvent les dépendances d'objets sur des listes plus petites, mais sans avoir ˆà charger des zones avec tous les objets contenus dedans. Je peux travailler sur des zones très grandes, même sur plusieurs pays (ce qui est impossible si on n'a pas assez de mémoire, sans faire de nombreuses erreurs et dépendre entièrement de l'analyse à postériori par des outils en ligne externes dont on ne sait pas quand il feront leur analyse ni comment les autres interprêteront les oublis). J'ai donc une série de fichiers OSM en cache local, tous d'une taille voisine de 200 Mo à 4 Go, créés de façn plus ou moins thématique. Je m'en sors très bien pour les mises à jour même en évitant les conflits d'édition et aussi en n'ayant jamais à les rafraîchir en totalité (ce qui prendrait trop de ressources sur le serveur et trop souvent). Mes amis sont: CTRL+ALT+D et "mettre à jour les modifications" (avant d'envoyer quoi que ce soit). Aussi j'utilise abondamment le validateur (qui lui aussi a besoin de beaucoup de mémoire de travail). Essaye le passage en 64 bits au lieu de laisser par défaut en 32 bits, tu verras combien JOSM est BEAUCOUP plus performant dans ce mode !
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
