Maxthon est il rapide ?

[Novembre]

Bonjour,

 

Y a t'il des raisons -ou des faits établis- qui permettraient de dire que Maxthon est plus rapide que IE :

1- Pour le rendu d'une page donnée, surtout composée de texte et d'îcones (pas d'images).

2- Pour l'exécution de programmes en Java ?

 

Je parle bien sûr de vitesse d'exécution, en dehors de tout problème de temps de chargement.

 

Bon, ma question est peut être bête parce que la sous-couche de maxthon c'est IE (j'ai adopté le point de vue "sous-couche"), mais comme je ne prétends pas comprendre la technique qu'il y a derrière, je la pose quand même . C'est surtout la deuxième partie qui m'intéresse.

 

A bientôt !

[babyssou]

Bonjour,

 

Y a t'il des raisons -ou des faits établis- qui permettraient de dire que Maxthon est plus rapide que IE :

1- Pour le rendu d'une page donnée, surtout composée de texte et d'îcones (pas d'images).

2- Pour l'exécution de programmes en Java ?

 

Je parle bien sûr de vitesse d'exécution, en dehors de tout problème de temps de chargement.

 

Bon, ma question est peut être bête parce que la sous-couche de maxthon c'est IE (j'ai adopté le point de vue "sous-couche"), mais comme je ne prétends pas comprendre la technique qu'il y a derrière, je la pose quand même . C'est surtout la deuxième partie qui m'intéresse.

 

A bientôt !

Bonjour Novembre

 

Pour moi, IE et Maxthon, pour l'ouverture d'une page (donc eux déjà ouverts), c'est obligatoirement la même chose :

 

1 - ce que l'on appelle les "moteurs" (MSHTML et GECKO) ne sont en fait que des parseurs de code, c'est à dire une moulinette qui te prend le code lettre après lettre, l'analyse et l'interprète, donc c'est lui qui détermine la vitesse de chargement de la page (faire un parseur HTML était d'ailleurs un sujet de TP dans les écoles d'informatique il y a quelques annnées)

2 - Pour Java, toute appli démarre une "console" en arrière plan, c'est elle qui est si longue à charger (mais une fois fait, les applis en Java ont un temps de réponse négligable)

 

3 - Ce qui peut faire des différences, ce sont les plugins (filtres) actifs au moment du chargement puisqu'ils parsent eux-aussi la page (et avant le moteur) pour rajouter ou enlever du code.

 

HTML et Java, c'est de l'interprété, pas du compilé, donc forcément, il te faut quelque part un truc qui va le transformer en langage directement compréhensible par l'OS.

 

PS : je viens de voir que l'auto-logon au forum ne marchait pas dans le "monde obscur". C'est pas un problème, mais si quelqu'un sait pourquoi, je ferai la modif pour que ça marche

[Ldfa]

2 - Pour Java, toute appli démarre une "console" en arrière plan, c'est elle qui est si longue à charger (mais une fois fait, les applis en Java ont un temps de réponse négligable)

Java est compilé, mais c'est pas du ByteCode. C'est à dire que ce n'est pas de l'assembleur. C'est pour celà que Java est multi-OS et donc multi-plateforme, mais l'interpréteur Java est obligé de traduire ce ByteCode en assembleur au final, et donc de perdre un peu de temps pour celà. C'est d'autant plus lent que l'on a une machine peu puissante.

PS : je viens de voir que l'auto-logon au forum ne marchait pas dans le "monde obscur". C'est pas un problème, mais si quelqu'un sait pourquoi, je ferai la modif pour que ça marche

Peut-être un problème de cookie... Je vais essayer pour voir.

[ricouz]

Salut à tous

 

mais l'interpréteur Java est obligé de traduire ce ByteCode en assembleur au final,

 

Si on veut être puriste c'est pas en assembleur, c'est en binaire que le ByteCode est traduit.

 

Je dirai que l'assembleur est encore un autre langage qui permet de rendre lisible le langage machine. En fait la machine virtuelle de Java transforme le ByteCode en langage machine, mais je pinaille Ldfa

[Ldfa]

Salut à tous

Si on veut être puriste c'est pas en assembleur, c'est en binaire que le ByteCode est traduit.

 

Je dirai que l'assembleur est encore un autre langage qui permet de rendre lisible le langage machine. En fait la machine virtuelle de Java transforme le ByteCode en langage machine, mais je pinaille Ldfa

Non, tu as entièrement raison, c'est bien en langage machine et non pas en assembleur effectivement, Ricouz. Je me suis honteusement trompé, je dois le reconnaître.

[Novembre]

Hum.

Je ne comprends pas tout. Je ne sais pas ce qu'est un "parseur", j'ai l'impression d'être dans un conte de Claude Ponti ou dans une BD de Philemon

 

 

Bon. Je comprends que si on fait une course de vitesse IE et M arrivent en même temps.

 

Pourtant j'ai eu l'impression. Peut être que j'ai trop voulu voir Maxthon plus rapide.

 

En tout cas merci pour vos explications !

[ricouz]

Disons pour faire très simple que Maxthon n'est pas un navigateur, c'est un outil qui utilise le moteur d'IE pour afficher les pages, donc par conséquent il ne peut pas être plus rapide qu'IE puisqu'il utilise IE pour tout ce qui est rendu de pages, au pire et au contraire il pourrait être plus lent.

[babyssou]

Non, tu as entièrement raison, c'est bien en langage machine et non pas en assembleur effectivement, Ricouz. Je me suis honteusement trompé, je dois le reconnaître.

Moins que moi quand même qui avait oublié qu'après avoir écrit son code java, il fallait le passer au compilateur (et pourtant, j'en ai écrit !)

 

C'est d'ailleurs une des ambiguités de Java ! Pourquoi n'ont-ils pas opté, comme pour REXX, TCL et PERL, dans l'interprété ??? (TCL est un modèle de puissance, c'est le seul que je recommande pour des applis de production) Pour protéger le code ??? On trouve de très bons "reverser" java sans aucun problème !

 

(parseur = analyseur de code morceau par morceau)

[Novembre]

Merci encore pour les explications.

 

J'étais tombé par hasard sur un post de Jimi que j'avais peut être lu trop vite et j'avais cru comprendre qu'il y avait une machine java intégrée dans Maxthon. Cet intégration aurait pu expliquer une exécution plus rapide par Maxthon.

 

Concernant le choix "interprété" versus "compilé" les raisons de choisir ne sont elles pas toujours un peu les mêmes ? les programmes compilés sont plus concis et plus rapides que les programmes interprétés... enfin c'est la règle générale.