Je dirais que c'est qqch de trés logique par rapport a l'allocation mémoire, en général :
- le programme a un certain nombre de données de taille fixe (strucuture, objet, ... etc)
- le programme veut réutiliser la mémoire peut aprés l'avoir liberée.
les memory slice est un manager de mémoire adapté a un certain type de donnée : les éléments de taille fixe, en grand nombre.
valgrind sait faire
Pour valgrind: ca doit etre possible, valgrind peut dire qui a alloué la mémoire, voir l'empilement des appels:
Memcheck reports these errors as soon as they occur, giving the source line number at which it occurred, and also a stack trace of the functions called to reach that line. Memcheck tracks addressability at the byte-level, and initialisation of values at the bit-level. As a result, it can detect the use of single uninitialised bits, and does not report spurious errors on bitfield operations. Memcheck runs programs about 10--30x slower than normal.
ce qu'il manque
Ce que j'aimerais voir (j'ai pas cherché donc ca existe peut etre déja)
c'est une api assez générique de gestion de mémoire (genre les allocator de la STL) dans la glib,
comme ca on pourrait changer en une ligne (set-default-allocatore) toutes les allocation sans avoir a changer chaque malloc/free.
De plus si ils pouvais mettre un profiler de mémoire dans leurs API, ca aiderais tout le monde, surtout pour faire du code de qualité.
A set of functions used to perform memory allocation. The same GMemVTable must be used for all allocations in the same program; a call to g_mem_set_vtable(), if it exists, should be prior to any use of GLib.
En effet, dans sa dernière version, le bureau gnome standard est maintenant dépendant de python, et on voit qu'il y a une force qui veut en faire de même avec .NET(mono). En effet, il ne s'agit pas ici d'avoir des "applications additionnelles" gnome dépendantes de tel ou tel (bloat&&useless)ware mais bien d'en d'obliger l'installation pour le déploiement d'un bureau gnome de base.
Ca sent vraiment pas bon.
Il n'y a pas à favoriser tel ou tel language de haut niveau en forçant la dépendance sur une couche additionnelle (statégiquement pilotée par qui... allez un peu de bon sens messieurs et mesdames...) du bureau de base.
Bref... que je l'ai déjà dit, maintenant le libre attire les convoitisent et des entreprises vont tenter de se rendre indispensables à son fonctionnement de base... et si la communauté se laisse faire, le libre n'aura plus que de libre des licences.
Je n'ai absolument rien contre python, tout au contraire.
Je suis par contre complètement opposé à toutes les dépendances sur des langages de haut niveau du bureau gnome de base. Il n'y a pas à favoriser un langage de haut niveau plus qu'un autre, surtout qu'il y en a une plétore.
Mais je ne vois pas d'inconvénients à ce que les applications additionnelles soient faites en langages de haut niveau, tant que leur installation reste à la discrétion de l'utilisateur.
Mais ce que je voulais mettre en évidence sur ce fil de discussion, c'est qu'il semble qu'il y ait une récupération du bureau de Gnome, un peu comme une récupération politique, avec des méthodes qui me rappellent celles d'une grosse boîte bien connue.
# Speed King ...g_slice
Posté par mathieu mathieu (site web personnel) . Évalué à 0.
Un objet libéré peut être encore utilisé... comment est ce que cela fonctionne? il y a une sorte de garbage collector comme en java?
Je me demande également comment cela se comporte lorsque l'on utilise des outils genre valgrind ...
[^] # Re: Speed King ...g_slice
Posté par Gregplus . Évalué à 6.
[^] # Re: Speed King ...g_slice
Posté par patrick_g (site web personnel) . Évalué à 4.
http://developer.gnome.org/doc/API/2.0/glib/glib-Memory-Slic(...)
[^] # Re: Speed King ...g_slice
Posté par ham . Évalué à 3.
(Tel que je l'ai compris)
Je dirais que c'est qqch de trés logique par rapport a l'allocation mémoire, en général :
- le programme a un certain nombre de données de taille fixe (strucuture, objet, ... etc)
- le programme veut réutiliser la mémoire peut aprés l'avoir liberée.
les memory slice est un manager de mémoire adapté a un certain type de donnée : les éléments de taille fixe, en grand nombre.
valgrind sait faire
Pour valgrind: ca doit etre possible, valgrind peut dire qui a alloué la mémoire, voir l'empilement des appels:
Source: http://valgrind.org/info/tools.html#memcheck
ce qu'il manque
Ce que j'aimerais voir (j'ai pas cherché donc ca existe peut etre déja)
c'est une api assez générique de gestion de mémoire (genre les allocator de la STL) dans la glib,
comme ca on pourrait changer en une ligne (set-default-allocatore) toutes les allocation sans avoir a changer chaque malloc/free.
De plus si ils pouvais mettre un profiler de mémoire dans leurs API, ca aiderais tout le monde, surtout pour faire du code de qualité.
[^] # Re: Speed King ...g_slice
Posté par Yusei (Mastodon) . Évalué à 3.
# Gnome est en danger!
Posté par sylware . Évalué à 2.
En effet, dans sa dernière version, le bureau gnome standard est maintenant dépendant de python, et on voit qu'il y a une force qui veut en faire de même avec .NET(mono). En effet, il ne s'agit pas ici d'avoir des "applications additionnelles" gnome dépendantes de tel ou tel (bloat&&useless)ware mais bien d'en d'obliger l'installation pour le déploiement d'un bureau gnome de base.
Ca sent vraiment pas bon.
Il n'y a pas à favoriser tel ou tel language de haut niveau en forçant la dépendance sur une couche additionnelle (statégiquement pilotée par qui... allez un peu de bon sens messieurs et mesdames...) du bureau de base.
Bref... que je l'ai déjà dit, maintenant le libre attire les convoitisent et des entreprises vont tenter de se rendre indispensables à son fonctionnement de base... et si la communauté se laisse faire, le libre n'aura plus que de libre des licences.
[^] # Re: Gnome est en danger!
Posté par Erwan . Évalué à 1.
[^] # Re: Gnome est en danger!
Posté par sylware . Évalué à 2.
Je suis par contre complètement opposé à toutes les dépendances sur des langages de haut niveau du bureau gnome de base. Il n'y a pas à favoriser un langage de haut niveau plus qu'un autre, surtout qu'il y en a une plétore.
Mais je ne vois pas d'inconvénients à ce que les applications additionnelles soient faites en langages de haut niveau, tant que leur installation reste à la discrétion de l'utilisateur.
Mais ce que je voulais mettre en évidence sur ce fil de discussion, c'est qu'il semble qu'il y ait une récupération du bureau de Gnome, un peu comme une récupération politique, avec des méthodes qui me rappellent celles d'une grosse boîte bien connue.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.