Avez vous déjà remarquez que... - Page 1

... plus il y a de lignes entrées dans l'écran home de votre TI68k, plus les performances de certains programmes peuvent être affectées ?
C'est en faisant des bench avec le programme que je développe actuellement que j'ai pû faire le lien entre les résultat très variables d'une fois sur l'autre. Bon ce n'est peut-être pas le programme tout entier qui est affecté (dans mon cas c'est seulement la partie compilation qui utilise pas mal de malloc, free et de petites fonctions).
Et à chaque fois que je vire toutes les entrées dans l'écran home, j'obtiens de très bonnes performance tandis que lorsque j'arrive à 30/30 par exemple cette partie du programme va 1/4 moins vite.

Bon alors déjà je voulais savoir s'il est possible qu'il y est un lien entre le nombre de lignes entrées dans l'écran home et les performances de certains programmes (ou parties ?) et de quoi cela vient ? Et puis aussi ou sont stockés toutes ces données (ça peut-être des opérations ou des noms de programmes) ? Et enfin si il y avait un moyen de ne plus être dépendant de ça ?

les lignes sont sotckées en ram, qd on reaffiche le home, faut reafficher les 30 lignes, ça fait ramer... nan franchement j'en sais pas plus, mais ds le programme meme j'ai jamais remarqué une baisse de performance

Ben si y a moins de RAM dispo, ça peut toujours entraîner une baisse de performance, tout dépend du programme non ?
(p.ex. le mien rame s'il y a peu de RAM parce qu'il passe son temps à décompresser des blocs de données, alors que sinon il les garde dans un cache).
Enfin, c'est vrai que stocker 30 lignes ça ne doit pas consommer tant de mémoire que ça, donc je ne sais pas...

Il y a un phénomène assez bizarre sur la mienne, quand à un programme est entré dans la barre des formules que j'éteint ma TI que je la rallume et que j'appuye seulement sur enter, le programme et plus lent que si je vais dans le menu Var-Link, je choisit le fichier et je le lance.

Mais benchs mon confirmé ce problème, ça le fait avec la majoritée des programmes et je ne sais pas de quoi ça vient, peut être la fonction de consommation du CPU...

Oui mais il faut faire des bench avec les timer pour s'en rendre compte.
Dans mes moteurs (2d et 3d) il n'y a pas de performance quoique j'ai juste les fps alors que dans mon programme je suis au 1/20 s près et la partie de mon programme en question varie entre 23 et 30 vingtième de secondes.

Heu... Je n'ai jamais constaté un quelconque ralentissement avec le HOME plein. Comme l'a dit liquid, la seule chose qui ralenti c'est quand on quitte le programme et qu'AMS réaffiche tout (logique).

J'ai aussi fait une barre de progression où l'on voit très bien cela : ça saccade bcp qd ça prend plus de tps.

Si tu fais beaucoup d'allocations/désallocations, c'est normal que ce soit plus lent. Sinon, il n'y absolument aucune raison...

Un écran home avec un historique de 30 élements et des calculs ordinaires, ça ne doit pas prendre grand chose ?

Apparament ça vient des malloc, free que j'utilise énormément dans mes fonctions de chaîne. Maintenant j'alloue tout avant et il n'y a plus de différences.

Vertyos> s'il y a bcp de handles alloués, il y a des chances pour que le TIOS galère un peu pour se déplacer à travers le heap. En fait il n'y a pas une "liste des trous", mais uniquement des informations sur chaque trou au début du trou, donc pour trouver le trou, il faut d'abord se farcir tous les handles qu'il y a avant...

Tu peux rééxpliquer ? j'ai rien compris :/

Il dit que AMS n'a pas une table centrale de gestion de la RAM. Il y a juste le mappage handles->adresse pour que HeapDeref soit rapide, mais pour tout le reste, par exemple pour trouver un endroit libre, AMS est obligé de traverser à chaque fois la RAM entière pour regarder dans le header de chaque bloc de mémoire (alloué ou libre qu'il soit).

Tout comme PedroM Desole de toute facon, c'est pas capital en general.

LE probleme du Home plus lent, c'est qu'il faut environ 3s pour que les ti-hw1 retrouvent toute leur peche avant le demarrage.

Kevin : Je comprends mieux ton explication... celle de Pollux est vraiment incompréhensible :

il y a des chances pour que le TIOS galère un peu pour se déplacer à travers le heap. En fait il n'y a pas une "liste des trous", mais uniquement des informations sur chaque trou
au début du trou, donc pour trouver le trou, il faut d'abord se farcir tous les handles qu'il y a avant...

moi j'avais compris

Oui mais je suis un peu bête

Ben oué mais j'étais un peu à l'arrache donc j'avais pas trop le temps d'expliquer bien... La prochaine fois je rajouterai des balises