Le rapport, c'est que les deux ouvrent une fenêtre ou on tape du texte dedans :-)
Blague à part, 14.9MiB pour Gnotes (hors librairies partagées), Tomboy est plus gros de ~8Mib (~23Mib), ça devient vraiment du n'importe quoi pour la gestion des ressources.
Ce ne sont pas les ~200 caractères par notes qui vont aller occuper entre 15 et 20Mib de mémoire vive.
Et pourtant, quand je programme en Python ou Java, je suis le premier à laisser le GB à se débrouiller tout seul (en dehors de d'ajouter variable=null; pour faciliter son travail) à utiliser les fonctions HashMap ou Listes qui doivent bien occuper x fois plus de mémoire qu'un tableau d'octets gérée à la mimine.
Mais x doit surement être inférieur à 10 à la méga louche.
Ok, on a des Gib, mais sans vouloir optimiser en assembleur, il y a une différence entre choisir le mauvais algorithme (occupation mémoire) et un algorithme plus adapté par définition.
C'est exactement le même débat avec la vitesse, ça ne sert à rien de programmer un tri à bulle en assembleur quand un shell sort même en basic sera plus rapide sur des millions d'éléments.
Après il y a les buffers écrans, une zone 640x512 en 24bits, c'est un buffer de ~1Mib, ce buffer est pris du côté de X11 ou de l'application ? (si c'est du côté de X11, c'est pire que j'imaginais).
[^] # Re: Les deux sont bloated
Posté par darkleon . En réponse à la dépêche Tomboy vs Gnote. Évalué à 1.
Blague à part, 14.9MiB pour Gnotes (hors librairies partagées), Tomboy est plus gros de ~8Mib (~23Mib), ça devient vraiment du n'importe quoi pour la gestion des ressources.
Ce ne sont pas les ~200 caractères par notes qui vont aller occuper entre 15 et 20Mib de mémoire vive.
Et pourtant, quand je programme en Python ou Java, je suis le premier à laisser le GB à se débrouiller tout seul (en dehors de d'ajouter variable=null; pour faciliter son travail) à utiliser les fonctions HashMap ou Listes qui doivent bien occuper x fois plus de mémoire qu'un tableau d'octets gérée à la mimine.
Mais x doit surement être inférieur à 10 à la méga louche.
Ok, on a des Gib, mais sans vouloir optimiser en assembleur, il y a une différence entre choisir le mauvais algorithme (occupation mémoire) et un algorithme plus adapté par définition.
C'est exactement le même débat avec la vitesse, ça ne sert à rien de programmer un tri à bulle en assembleur quand un shell sort même en basic sera plus rapide sur des millions d'éléments.
Après il y a les buffers écrans, une zone 640x512 en 24bits, c'est un buffer de ~1Mib, ce buffer est pris du côté de X11 ou de l'application ? (si c'est du côté de X11, c'est pire que j'imaginais).