maintenant que vous le dites, je trouve effectivement mon treo un peu trop lent à réagir (sincèrement)
Lent pour aller d'où à où par exemple ?
Lent lorsque je change d'application (en appuyant sur le bouton "maison" par ex). Passer du téléphone aux applications est aussi assez lourd.
Autrement dit, c'est le lancement du launcher que tu trouves lent. Seulement, c'est une des applications de base donc en ARM natif, sans émulation...
sebastienmarty
anonymous wrote:
Le 15/06/2009 18:59, Patrick V a écrit : > anonymous a écrit : >>> Et surtout, tu ne t'étais même pas aperçu que tes applications Palm >>> étaient émulées, ce qui rend ton discours assez peu convainquant ;-) > >> maintenant que vous le dites, je trouve effectivement mon treo un peu >> trop lent à réagir (sincèrement) > > Lent pour aller d'où à où par exemple ? Lent lorsque je change d'application (en appuyant sur le bouton "maison" par ex). Passer du téléphone aux applications est aussi assez lourd.
Ce dont tu ne t'étais jamais aperçu jusque là, ça ne doit donc pas être si dramatique...
-- [SbM] <http://sebastienmarty.free.fr> - <http://tradintosh.free.fr> <http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr> "If the French were really intelligent, they'd speak English" (W. Sheed)
anonymous <anonymous@world.org> wrote:
Le 15/06/2009 18:59, Patrick V a écrit :
> anonymous a écrit :
>>> Et surtout, tu ne t'étais même pas aperçu que tes applications Palm
>>> étaient émulées, ce qui rend ton discours assez peu convainquant ;-)
>
>> maintenant que vous le dites, je trouve effectivement mon treo un peu
>> trop lent à réagir (sincèrement)
>
> Lent pour aller d'où à où par exemple ?
Lent lorsque je change d'application (en appuyant sur le bouton "maison"
par ex).
Passer du téléphone aux applications est aussi assez lourd.
Ce dont tu ne t'étais jamais aperçu jusque là, ça ne doit donc pas être
si dramatique...
--
[SbM]
<http://sebastienmarty.free.fr> - <http://tradintosh.free.fr>
<http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr>
"If the French were really intelligent, they'd speak English" (W. Sheed)
Le 15/06/2009 18:59, Patrick V a écrit : > anonymous a écrit : >>> Et surtout, tu ne t'étais même pas aperçu que tes applications Palm >>> étaient émulées, ce qui rend ton discours assez peu convainquant ;-) > >> maintenant que vous le dites, je trouve effectivement mon treo un peu >> trop lent à réagir (sincèrement) > > Lent pour aller d'où à où par exemple ? Lent lorsque je change d'application (en appuyant sur le bouton "maison" par ex). Passer du téléphone aux applications est aussi assez lourd.
Ce dont tu ne t'étais jamais aperçu jusque là, ça ne doit donc pas être si dramatique...
-- [SbM] <http://sebastienmarty.free.fr> - <http://tradintosh.free.fr> <http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr> "If the French were really intelligent, they'd speak English" (W. Sheed)
anon
SbM a écrit : er du téléphone aux applications est aussi assez lourd.
Ce dont tu ne t'étais jamais aperçu jusque là, ça ne doit donc pas être si dramatique...
quel argument plein d'esprit :) très convainquant.
SbM a écrit :
er du téléphone aux applications est aussi assez lourd.
Ce dont tu ne t'étais jamais aperçu jusque là, ça ne doit donc pas être
si dramatique...
quel argument plein d'esprit :) très convainquant.
Autrement dit, c'est le lancement du launcher que tu trouves lent. Seulement, c'est une des applications de base donc en ARM natif, sans émulation...
rien ne garantit que le pb vient du launcher. Aucun profiling de performances n'a été effectué.
Patrick V
anon a écrit :
Autrement dit, c'est le lancement du launcher que tu trouves lent. Seulement, c'est une des applications de base donc en ARM natif, sans émulation...
rien ne garantit que le pb vient du launcher. Aucun profiling de performances n'a été effectué.
Le launcher est le point commun aux exemples que tu as donnés. Et puis, lors du passage d'une application au launcher, il n'y a que 2 coupables possibles, l'application que l'on quitte et le launcher. Or, quitter une application est rapide, juste quelques APIs de nettoyage des données.
Par contre, l'entrée dans le Launcher nécessite que ce dernier fasse le tour des applications, les trie, lise les préférences, etc. Ajoute à ça la lecture éventuelle des VFS (internes ou externes).
Pour revenir au cas général, l'émulation 68k est transparente pour la très très grande majorité des applications, ne serait-ce que parce ce que les APIs sont appelées en natif ARM, avec juste une courte étape de changements d'indiens. Ce n'est que sur les applications qui font tourner du code avec peu d'API que l'émulation pose problème. Par exemple, j'avais porté un algorithme assez complexe de traitement d'image, avec un peu d'interface autour ; en passant l'algo lui-même en natif, le gain de performances a été important.
anon a écrit :
Autrement dit, c'est le lancement du launcher que tu trouves lent.
Seulement, c'est une des applications de base donc en ARM natif, sans
émulation...
rien ne garantit que le pb vient du launcher. Aucun profiling de
performances n'a été effectué.
Le launcher est le point commun aux exemples que tu as donnés. Et puis,
lors du passage d'une application au launcher, il n'y a que 2 coupables
possibles, l'application que l'on quitte et le launcher. Or, quitter une
application est rapide, juste quelques APIs de nettoyage des données.
Par contre, l'entrée dans le Launcher nécessite que ce dernier fasse le
tour des applications, les trie, lise les préférences, etc. Ajoute à ça
la lecture éventuelle des VFS (internes ou externes).
Pour revenir au cas général, l'émulation 68k est transparente pour la
très très grande majorité des applications, ne serait-ce que parce ce
que les APIs sont appelées en natif ARM, avec juste une courte étape de
changements d'indiens. Ce n'est que sur les applications qui font
tourner du code avec peu d'API que l'émulation pose problème. Par
exemple, j'avais porté un algorithme assez complexe de traitement
d'image, avec un peu d'interface autour ; en passant l'algo lui-même en
natif, le gain de performances a été important.
Autrement dit, c'est le lancement du launcher que tu trouves lent. Seulement, c'est une des applications de base donc en ARM natif, sans émulation...
rien ne garantit que le pb vient du launcher. Aucun profiling de performances n'a été effectué.
Le launcher est le point commun aux exemples que tu as donnés. Et puis, lors du passage d'une application au launcher, il n'y a que 2 coupables possibles, l'application que l'on quitte et le launcher. Or, quitter une application est rapide, juste quelques APIs de nettoyage des données.
Par contre, l'entrée dans le Launcher nécessite que ce dernier fasse le tour des applications, les trie, lise les préférences, etc. Ajoute à ça la lecture éventuelle des VFS (internes ou externes).
Pour revenir au cas général, l'émulation 68k est transparente pour la très très grande majorité des applications, ne serait-ce que parce ce que les APIs sont appelées en natif ARM, avec juste une courte étape de changements d'indiens. Ce n'est que sur les applications qui font tourner du code avec peu d'API que l'émulation pose problème. Par exemple, j'avais porté un algorithme assez complexe de traitement d'image, avec un peu d'interface autour ; en passant l'algo lui-même en natif, le gain de performances a été important.
sebastienmarty
anon wrote:
SbM a écrit : er du téléphone aux applications est aussi assez lourd. > > Ce dont tu ne t'étais jamais aperçu jusque là, ça ne doit donc pas être > si dramatique... >
quel argument plein d'esprit :) très convainquant.
Merci ;)
-- [SbM] <http://sebastienmarty.free.fr> - <http://tradintosh.free.fr> <http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr> "If the French were really intelligent, they'd speak English" (W. Sheed)
anon <anon@anon.com> wrote:
SbM a écrit :
er du téléphone aux applications est aussi assez lourd.
>
> Ce dont tu ne t'étais jamais aperçu jusque là, ça ne doit donc pas être
> si dramatique...
>
quel argument plein d'esprit :) très convainquant.
Merci ;)
--
[SbM]
<http://sebastienmarty.free.fr> - <http://tradintosh.free.fr>
<http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr>
"If the French were really intelligent, they'd speak English" (W. Sheed)
SbM a écrit : er du téléphone aux applications est aussi assez lourd. > > Ce dont tu ne t'étais jamais aperçu jusque là, ça ne doit donc pas être > si dramatique... >
quel argument plein d'esprit :) très convainquant.
Merci ;)
-- [SbM] <http://sebastienmarty.free.fr> - <http://tradintosh.free.fr> <http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr> "If the French were really intelligent, they'd speak English" (W. Sheed)
anon
Le 16.06.2009 17:15, Patrick V a écrit :
anon a écrit : Le launcher est le point commun aux exemples que tu as donnés. Et puis, lors du passage d'une application au launcher, il n'y a que 2 coupables possibles, l'application que l'on quitte et le launcher. Or, quitter une application est rapide, juste quelques APIs de nettoyage des données.
Par contre, l'entrée dans le Launcher nécessite que ce dernier fasse le tour des applications, les trie, lise les préférences, etc. Ajoute à ça la lecture éventuelle des VFS (internes ou externes).
Pour revenir au cas général, l'émulation 68k est transparente pour la très très grande majorité des applications, ne serait-ce que parce ce que les APIs sont appelées en natif ARM, avec juste une courte étape de changements d'indiens. Ce n'est que sur les applications qui font tourner du code avec peu d'API que l'émulation pose problème. Par exemple, j'avais porté un algorithme assez complexe de traitement d'image, avec un peu d'interface autour ; en passant l'algo lui-même en natif, le gain de performances a été important.
tout ceci n'est qu'hypothèse non vérifiée. Sans profiling précis des performances (je ne parle pas des résultats de simulation farfelus), on ne peut rien garantir. Quitter une application émulée pour coûter cher si celle-ci a été mal programmée, ou si l'émulateur est peu performant... Le travail du launcheur que vous citez ne semble pas être consommateur de temps: un tri coute O(n log n) ou O(n3) au pire cas. Le parcours des préférences coute O(n). Ayant 40 applications, cela ne freinerait pas le launcheur au point de le sentir assez lent. Peut être que l'interraction avec la couche système "temps réel" du téléphone treo coûte cher. Là aussi, ce n'est qu'hypothèse non vérifiée, je ne connais pas bien l'architecture système du Treo 680.
Le 16.06.2009 17:15, Patrick V a écrit :
anon a écrit :
Le launcher est le point commun aux exemples que tu as donnés. Et puis,
lors du passage d'une application au launcher, il n'y a que 2 coupables
possibles, l'application que l'on quitte et le launcher. Or, quitter une
application est rapide, juste quelques APIs de nettoyage des données.
Par contre, l'entrée dans le Launcher nécessite que ce dernier fasse le
tour des applications, les trie, lise les préférences, etc. Ajoute à ça
la lecture éventuelle des VFS (internes ou externes).
Pour revenir au cas général, l'émulation 68k est transparente pour la
très très grande majorité des applications, ne serait-ce que parce ce
que les APIs sont appelées en natif ARM, avec juste une courte étape de
changements d'indiens. Ce n'est que sur les applications qui font
tourner du code avec peu d'API que l'émulation pose problème. Par
exemple, j'avais porté un algorithme assez complexe de traitement
d'image, avec un peu d'interface autour ; en passant l'algo lui-même en
natif, le gain de performances a été important.
tout ceci n'est qu'hypothèse non vérifiée.
Sans profiling précis des performances (je ne parle pas des résultats de
simulation farfelus), on ne peut rien garantir.
Quitter une application émulée pour coûter cher si celle-ci a été mal
programmée, ou si l'émulateur est peu performant...
Le travail du launcheur que vous citez ne semble pas être consommateur
de temps: un tri coute O(n log n) ou O(n3) au pire cas. Le parcours des
préférences coute O(n). Ayant 40 applications, cela ne freinerait pas le
launcheur au point de le sentir assez lent.
Peut être que l'interraction avec la couche système "temps réel" du
téléphone treo coûte cher. Là aussi, ce n'est qu'hypothèse non vérifiée,
je ne connais pas bien l'architecture système du Treo 680.
anon a écrit : Le launcher est le point commun aux exemples que tu as donnés. Et puis, lors du passage d'une application au launcher, il n'y a que 2 coupables possibles, l'application que l'on quitte et le launcher. Or, quitter une application est rapide, juste quelques APIs de nettoyage des données.
Par contre, l'entrée dans le Launcher nécessite que ce dernier fasse le tour des applications, les trie, lise les préférences, etc. Ajoute à ça la lecture éventuelle des VFS (internes ou externes).
Pour revenir au cas général, l'émulation 68k est transparente pour la très très grande majorité des applications, ne serait-ce que parce ce que les APIs sont appelées en natif ARM, avec juste une courte étape de changements d'indiens. Ce n'est que sur les applications qui font tourner du code avec peu d'API que l'émulation pose problème. Par exemple, j'avais porté un algorithme assez complexe de traitement d'image, avec un peu d'interface autour ; en passant l'algo lui-même en natif, le gain de performances a été important.
tout ceci n'est qu'hypothèse non vérifiée. Sans profiling précis des performances (je ne parle pas des résultats de simulation farfelus), on ne peut rien garantir. Quitter une application émulée pour coûter cher si celle-ci a été mal programmée, ou si l'émulateur est peu performant... Le travail du launcheur que vous citez ne semble pas être consommateur de temps: un tri coute O(n log n) ou O(n3) au pire cas. Le parcours des préférences coute O(n). Ayant 40 applications, cela ne freinerait pas le launcheur au point de le sentir assez lent. Peut être que l'interraction avec la couche système "temps réel" du téléphone treo coûte cher. Là aussi, ce n'est qu'hypothèse non vérifiée, je ne connais pas bien l'architecture système du Treo 680.
Patrick V
anon a écrit :
tout ceci n'est qu'hypothèse non vérifiée.
Ceci (le cas général) est tout à fait vérifié.
Sans profiling précis des performances (je ne parle pas des résultats de simulation farfelus), on ne peut rien garantir.
Disons que quand on connait l'architecture et le développement Palm Os, on peut formuler des opinions éclairées.
Quitter une application émulée pour coûter cher si celle-ci a été mal programmée,
Il faut qu'elle soit particulièrement mal programmée, et ça ne sera pas un problème d'émulation.
ou si l'émulateur est peu performant...
L'émulation 68k de Garnet est tout sauf peu performante...
Le travail du launcheur que vous citez ne semble pas être consommateur de temps: un tri coute O(n log n)
Ce n'est pas le tri qui va prendre du temps, surtout avec le petit nombre d'applications. C'est de récupérer les informations sur les applications, en particulier les icônes. C'est particulièrement visible avec le Lifedrive, par exemple. Si tu as une carte SD, enlève-là, pour voir ce que ça donne.
Peut être que l'interraction avec la couche système "temps réel" du téléphone treo coûte cher.
Possible, mais pas en permanence. Attention aussi à la stack Bluetooth qui a tendance à boucler sur le Treo.
anon a écrit :
tout ceci n'est qu'hypothèse non vérifiée.
Ceci (le cas général) est tout à fait vérifié.
Sans profiling précis des performances (je ne parle pas des résultats de
simulation farfelus), on ne peut rien garantir.
Disons que quand on connait l'architecture et le développement Palm Os,
on peut formuler des opinions éclairées.
Quitter une application émulée pour coûter cher si celle-ci a été mal
programmée,
Il faut qu'elle soit particulièrement mal programmée, et ça ne sera pas
un problème d'émulation.
ou si l'émulateur est peu performant...
L'émulation 68k de Garnet est tout sauf peu performante...
Le travail du launcheur que vous citez ne semble pas être consommateur
de temps: un tri coute O(n log n)
Ce n'est pas le tri qui va prendre du temps, surtout avec le petit
nombre d'applications. C'est de récupérer les informations sur les
applications, en particulier les icônes. C'est particulièrement visible
avec le Lifedrive, par exemple. Si tu as une carte SD, enlève-là, pour
voir ce que ça donne.
Peut être que l'interraction avec la couche système "temps réel" du
téléphone treo coûte cher.
Possible, mais pas en permanence. Attention aussi à la stack Bluetooth
qui a tendance à boucler sur le Treo.
Sans profiling précis des performances (je ne parle pas des résultats de simulation farfelus), on ne peut rien garantir.
Disons que quand on connait l'architecture et le développement Palm Os, on peut formuler des opinions éclairées.
Quitter une application émulée pour coûter cher si celle-ci a été mal programmée,
Il faut qu'elle soit particulièrement mal programmée, et ça ne sera pas un problème d'émulation.
ou si l'émulateur est peu performant...
L'émulation 68k de Garnet est tout sauf peu performante...
Le travail du launcheur que vous citez ne semble pas être consommateur de temps: un tri coute O(n log n)
Ce n'est pas le tri qui va prendre du temps, surtout avec le petit nombre d'applications. C'est de récupérer les informations sur les applications, en particulier les icônes. C'est particulièrement visible avec le Lifedrive, par exemple. Si tu as une carte SD, enlève-là, pour voir ce que ça donne.
Peut être que l'interraction avec la couche système "temps réel" du téléphone treo coûte cher.
Possible, mais pas en permanence. Attention aussi à la stack Bluetooth qui a tendance à boucler sur le Treo.
