Discussion :

[Unusual]

Bonjour,

Dans notre application, je limite l'affichage des couches KML pour des nombres d'éléments trop importants. Exemple, si j'ai une commune avec plus de 20000 éléments, ce n'est pas la peine d'attendre...cela n'aboutit jamais.... J'ai effectué des tests pour déterminer approximativement ces valeurs limites acceptables en terme de temps (que ce soit en bêta 4 ou 5), et je n'effectue les chargements de couches que quand le nombre d'éléments est suffisamment affiné (donc zoom plus élevé). Voici un premier jet des mesures effectuées en secondes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Commune de THEIX (1150 Foyers)	
                         IE7       IE8     FF3.5x    Chrome3	   Safari4
VM XP Pro 512Mo           27                 18          13            13
Vista Core2Duo 4Go                 275       12          13

Cependant, au résultat de ces tests, il m'est apparu quelque chose de FLAGRANT...Je savais IE plus lent que Firefox pour la gestion DOM, mais alors là, c'est curieux quand même...IE8 est 10 fois plus lent que IE7 à charger un KML "moyen"...d'où certaines interrogations ? Y a-t-il un réglage qui puisse être effectué quelque part (paramétrage IE8 ?)

- J'ai essayé en bêta4 et pré-bêta5, cela ne change rien...
- J'ai activé/désactivé le mode de compatibilité IE7, cela ne change rien
- J'ai différé le recentrage après chargement de KML de 2 secondes, cela ne change rien (j'ai eu des pb avec IE7 nécessitant cette astuce sur certains postes)
- J'ai désactivé le recentrage après chargement de KML, cela ne change rien
- Le résultat est le même sous XP ou Vista (sait-on jamais ?...mais encore râté)
- J'ai ajouté une option de génération de mes KML pour les rendre plus compacts (mais moins lisibles)...Au cas où ce serait le parser d'IE qui ferait des siennes...mais là encore, pas de résultats "concluants".

Pour l'instant, je bride le nombre d'éléments possibles sous IE8 beaucoup plus bas que les autres navigateurs afin d'avoir "quand même un résultat" en quelques secondes...mais ce n'est pas satisfaisant. Il doit bien y avoir une explication, surtout en comparaison d'IE7 quand même un peu (beaucoup) plus véloce.
Est-ce encore une histoire d'évènements qui parasiteraient le traitement ? Quand je regarde la mémoire utilisée par le processus dans le gestionnaire de tâches durant le chargement du KML...cela monte au compte-gouttes...comme s'il y avait un frein...ou qu'IE8 "patinait"...

Si quelqu'un a des informations ou des lumières, je prends. Merci !

[gfilliere]

Tu as testé IE8 en mode de compatibilité IE7 pour voir si ça changeait quelque chose ? (<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"/> )

A une époque j'avais étudié aussi la différence de performance avec extractStyles : true et extractStyles : false et pour finir j'avais désactivé les styles parce que sous IE ça multipliait le temps de chargement par 10 pratiquement...

[dgrichard]

Le profilage devrait te donner des bonnes pistes :

Sous IE8 :

• charge ta page, puis <F12> (déboggueur), puis bouton « Démarrer le profilage » dans le déboggueur;

• Sous IE8 à nouveau : charge ton KML;

• Dans le déboggueur, bouton « Terminer le profilage ». Un tableau apparaît

Sous FF (>2.0 avec version de firebug récente) :

• charge ta page, appuie sur le bouton Firebug en haut à gauche du panneau, puis menu « profiler Javascript », charge le KML, désactive le profilage via le même menu;

• Dans la console tu obtiens le profilage ...

Pour info, je viens de trouver une optimisation lors les transformations de coordonnées qui ne s'effectuent que point par point (OpenLayers.Projection.transform) ... En passant un tableau, on gagne bien plus qu'un facteur 10

C'est particulièrement visible sur les transformations de vecteurs linéaires ou polygonaux ... Probablement pas ton cas