Taille d'un objet en mémoire
UniX
Membre
Salut.
J'ai à priori un pb sur un objet dont la taille augmente anormalement ....
Je souhaiterais le monitorer pour voir à quel moment il augmente. Existe t'il un moyen de voir sa taille en mémoire à un moment donné de l'exécution ?
J'ai à priori un pb sur un objet dont la taille augmente anormalement ....
Je souhaiterais le monitorer pour voir à quel moment il augmente. Existe t'il un moyen de voir sa taille en mémoire à un moment donné de l'exécution ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Donc en fait, j'ai une des variables d'instance d'un objet qui augmente, et je voudrais en connaà®tre sa taille.
Euh... La remarque est la même pour les variables d'instance.
Tout objet ou variable en C ou en Objective-C a une taille fixe.
Après, une partie de cette variable ou de cet objet peut être un pointeur qui peut être nil / NULL ou pointer sur une autre variable ou un autre objet qui a lui même une taille.
Tu veux peut-être dire que le nombre de références sur d'autres objets (en récursif) augmente ?
Ceci dit je ne sais pas comment faire. On peut coupler le terminal/debuger et visualiser l'augmentation/reduction mémoire lors du chargement/release d'un objet mais ce n'est pas précis (même si c'est plutôt fiable).
Mais bon, en général ce sont des structures genre liste chaà®nées etc. en pratique on ne voit pas grand chose à part des allocations de blocs mémoire.
J'enregistre cet objet sur disque sous forme de fichier (il s'agit du fichier library de Discoway).
Et je me suis aperçu que ce fichier, lors de l'import de certaines cartes, augmente énormement (3 ou 400 Mo alors qu'il ne devrait pas faire plus de 500 ou 600 ko ...), alors qu'il ne contient que des données peu "lourdes" ...
J'aurais donc voulu monitorer à quel moment dans le cycle d'importation il augmente.
Ce que je vais faire, c'est rajouter à divers endroits du cycle des enregistrement sur disque, et retourner en NSLog la taille du fichier.
Non, non, dans ce fichier, je n'y stoche pas les cartes, seulement les infos relatives à la carte, et qui me servent à remplir la tableView de gestion des cartes.
Le seul truc qui est sucpsceptible de peser, c'est la NSImage, mais ce n'est que la vignette des cartes qui s'affiche dans Infos .... Donc une image riquiqui .....
J'y suis dessus, je vais essayer de voir ce qui ne va pas .....
C'est pour ça que dans ce cas (utilisation mémoire assez notable) je parlais du terminal...
Pourquoi ne pas placer des points d'arrêt afin d'analyser à l'aide du debugeur et du terminal les importations un peu trop "lourdes" ?
A priori, ça viendrait de mes vignettes qui sont anormalement pas si riquiqui que ça !
Avec le terminal, tu pensais à quoi ?
T'es sur que les vignettes ne sont pas juste redimensionnée ?
Si tu veux comprimer tes vignettes ->
Riquiqui ça veut dire quoi pour toi ? Tu sais que si tu enregistres en bitmap, ça donne du 4 octets par pixel... Ca monte vite !
Pour obtenir les vignettes, j'ai le code suivant :
Là j'ai donc réduit les images, et j'ai une vignette d'environ 130x120 (c'est vérifié).
Ensuite, j'enregistre la vignette dans mon objet librairie en tant que NSImage. Mais théoriquement, même en bitmap, une image de 130x120, ça doit pas peser très lourd ....?
Supermic, quand tu dis "T'es sur que les vignettes ne sont pas juste redimensionnée ?", je penses qu'elles sont justes redimensionnées effectivement, mais que veux tu y faire de plus ?
J'en déduis, que le fait de réduire la taille d'une NSImage avec setSize: ne réduit pas pour autant son poids ?
Fais des vignettes en 240x240, ça te donneras un peu de marge comme ça (la mode à la haute definition en ce moment...) mais tout dépend de combien d'images sont stockées mais bon l'icône d'un fichier c'est déjà du 128x128 alors toi tu peux pousser un peu dans la logique des choses mais c'est du détail.
L'idéal aussi serait que ton fichier "library" sont en "bundle" (fichier plist + les images enregistrées en .png dans le dossier...) mais c'est également du détail...
Pour l'enregistrement en PNG :
Bon, j'ai résolu ce pb de fichier library qui grossissait à vu d'oeil.
Après avoir réduit la taille d'une image avec setSize:, il faut également l'écrire dans une autre image, afin de diminuer son poids.
:adios!:
Si un modérateur passe par ici, il serait peut être bon de scinder ce sujet en 2. On est parti sur le poids d'un objet, et fini sur des réductions d'images. Merci.
setSize: ne réduit en aucun cas l'image elle même, mais juste son "espace" d'affichage.
C'est pourquoi son poids reste le même, mais aussi pourquoi tu as galéré pour faire une réduction "jolie" (avec flou).
Normalement, un code "propre" de réduction d'image avec floutage devrait être comme suivant :
.
J'étais arrivé à avoir un code presque similaire, sauf que je faisais un setSize: sur la grande image, et que je n'avais pas mis le setShouldAntiAlias: (j'avoue ne pas avoir pensé que ça pouvais avoir un effet sur les images ...
Et le problème d'image mal redimensionnée, envolé !!!!!
Merci beaucoup Bru pour ect éclaircissement.
Schlum, tu vas pouvoir utiliser ça dans SudokuX également !
Bah j'aime bien ma méthode... Et je crée aussi le handle pour l'icône document en même temps...
Lorsque je resize à 500x500, c'est vraiment trop trop précis au point d'être moche. Apparemment l'antialiasing ne marche pas car que je mette no ou yes ça ne change rien sur mon image.
Pareil pour l'interpolation.
Voici mon code :
Qui est le même que celui de Bru..
Après je sauvegarde l'image comme ceci :
NSImageInterpolationHigh ?
Pour moi ce code marche nickel ....
Oops pardon, non c'est parce que j'avais testé le changement de l'interpolation, et que je mette low ou high ça ne change rien non plus...
Essayes peut être d'afficher l'image dans une NSImageView plutôt que de l'enregistrer sur le disque, pour vérifier que le pb n'est pas lors de l'enregistrement (on sait jamais ...).
Mais NSGraphicsContext ne veut toujours pas marcher (même sans l'enregistrement)