Mon appli est finie. Que reste-t-il à faire ?
Philippe49
Membre
Ma première appli est finie.
Que reste-t-il à faire ?
Je lis performance overview
Le chapitre commence par l'utilisation de top. Je préfère l'interface graphique Moniteur d'activités Est-ce que j'y perds quelque chose
Première surprise en lançant mon appli (en mode DEBUG), elle comporte 4 threads (?), alors que je n'en n'ai créé aucun, sauf peut-être un NSSpeechSynthesizer qui me semble fonctionner par ce biais.
AU bout de 10 minutes d'utilisation, la mémoire réelle s'est stabilisée à 35 Mo (je ne vois vraiment pas ce qui a pu créer 10 Mo : je crée une NSString que je fais lire au NSSpeechSynthesizer). A priori, il n'y a pas de fuite mémoire, on verra plus tard avec les autres outils. Le nombre de threads est passé régulièrement par 5 et 6, ce qui est logique si on admet le nombre initial de 4 threads + le NSSpeechSynthesizer qui doit fonctionner en thread.
Merci de vos éclaircissements, et du partage d'expérience.
[Fichier joint supprimé par l'administrateur]
Que reste-t-il à faire ?
Je lis performance overview
Le chapitre commence par l'utilisation de top. Je préfère l'interface graphique Moniteur d'activités Est-ce que j'y perds quelque chose
Première surprise en lançant mon appli (en mode DEBUG), elle comporte 4 threads (?), alors que je n'en n'ai créé aucun, sauf peut-être un NSSpeechSynthesizer qui me semble fonctionner par ce biais.
AU bout de 10 minutes d'utilisation, la mémoire réelle s'est stabilisée à 35 Mo (je ne vois vraiment pas ce qui a pu créer 10 Mo : je crée une NSString que je fais lire au NSSpeechSynthesizer). A priori, il n'y a pas de fuite mémoire, on verra plus tard avec les autres outils. Le nombre de threads est passé régulièrement par 5 et 6, ce qui est logique si on admet le nombre initial de 4 threads + le NSSpeechSynthesizer qui doit fonctionner en thread.
Merci de vos éclaircissements, et du partage d'expérience.
[Fichier joint supprimé par l'administrateur]
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
La mémoire réelle passe de 5,8 Mo à 17,5 Mo en vitesse de croisière
C'est le synthesizer qui fait augmenter de 10 Mo, puis une option de redimensionnement de la fenêtre de l'appli qui fait le petit reste.
[Fichier joint supprimé par l'administrateur]
Sinon, ton application utilise quoi à part NSSpeechSynthesizer ?
Certains éléments peuvent générer pour elles-mêmes des threads internes que tu n'as pas à gérer.
Pour en être sûr, demande :
[Edit] Rien qu'en faisant une appli Cocoa vide, il y a déjà 2 thread d'après "top"
Il s'agit d'une application ultra-simple, avec quelques bindings pour les préférences, le textField, et les options du tiroir. Il y a un panel preference, et un panel about. ... pas grand chose donc
Le code le plus long est le switch() dans la lecture de l'heure ..
J'essaie maintenant shark
Que faut-il y lire ?
[Fichier joint supprimé par l'administrateur]
not multi-threaded ... comme prévu
C'est pour l'optimisation des parties de code qui prennent beaucoup de temps processeur.
Avec le réglage comme l'indique l'image ci-dessous, on voit chaque rafraà®chissement partiel de l'interface. Rien de surprenant en ce qui concerne mon appli. Â
2) Il est bon de protéger son logiciel ...
tablier et eddy58 en ont parlé sur ce topic
[Fichier joint supprimé par l'administrateur]
Dans les performance Tools, on trouve une appli sympa : Thread Viewer
Dans mon cas, il semble y avoir
un thread qui agit régulièrement, la boucle d'évènements sans doute
un second qui apparaà®t lorsqu'on change le nombre, un très court instant : l'interface graphique serait treadée ?
Et le reste agit avec le NSSpeechSynthesizer dont 3 restent en sommeil.
Passage sous Leopard, c'est un peu du pareil au même (14 Mo en vitesse de croisière).
L'essai avec Malloc Debug donne des informations : La mémoire allouée utile ne dépasse pas 5 Mo et confirme qu'il n'y a pas de fuite mémoire.
Cela vient nuancer la lecture des 17,5 Mo du Moniteur d'activités, les 10 Mo semblant correspondre plutot à un espace réservé (appli, caches, ...) qu'à un espace réellement utilisé.
Conclusion :
Je suis dubitatif par rapport à tout cela .
Que faut-il en conclure ?
Passage sous Leopard
Lors de la prochaine mise à jour, comment faire en sorte que l'appli reste opérationelle sur Tiger et panther ?
Est-il possible de le vérifier sur mon MBP désormais Léopardisé ?
Par contre, pour tester, ben il aurait fallu garder ces systèmes, ou alors faire tester par quelqu'un qui les a.
j'ai toujours le 10.2.8, le 10.3.9 et le 10.4.5 même si j'utilise le 10.4.10.
Je peux éventuellement essayer, si ça t'interresse!!
Merci, tablier, j'installe le téléchargement dans quelques jours, il faut encore que je teste Sparkle.
Tu conserves Tiger et Panther sur des machines différentes ? ou tu utilises une partition ?
(mais il ne faut pas avoir un ordi trop récent... Sur mon G5, je peux avoir de 10.2.8 à 10.5 !)
Sur mon MBP j'avais Panther, une fois que ma fille aura fini de le squatter (en s'en faisant offrir un à la place), je devrais avoir une petite place. J'imagine que pour cela on crée une partition dans utilisateur de disque, et on y installe Panther. Mais cela doit dédoubler les applis de base, et le MBP n'a "que" 80 Go
Il va falloir le récupérer parce que XCode 3 commence au SDK 10.4u
Ah ? J'avais cru voir le 10.3.9 sur la version Bêta utilisée à mon boulot ???
Les deux! j'ai un G3 de 1998 qui fait touné MacOS 8.6, 9.2.2 et MacOSX 10.2.8
et un PB G4 sous 10.4.10 avec un disque externe partitionné pour 10.2.8, 10.3.9 et 10.4.5.
A certains moments j'ai l'impression d'être un collectionneur! :P
Tu as bien vu Schlum, et c'est toi Philippe qui n'a pas fait attention ....
En fait l'installation par défaut de Xcode 3 n'installe pas le SDK 10.3.9.
Il faut prendre le soin de choisir une installation personnalisée, et de cocher le SDK.
Ah merci UniX, je corrige cela