• # Speed King ...g_slice

    Posté par  (site web personnel) . Évalué à 0.

    Je viens de voir la documentation concernant g_slice_ http://developer.gnome.org/doc/API/2.0/glib/glib-Memory-Slic(...)

    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  . Évalué à 6.

      tu as mal lu/compris, ce n'est pas l'objet libéré qui peut être réutilisé mais son emplacement.
    • [^] # Re: Speed King ...g_slice

      Posté par  (site web personnel) . Évalué à 4.

      y'a un vilain point à la fin de ton URL !

      http://developer.gnome.org/doc/API/2.0/glib/glib-Memory-Slic(...)
    • [^] # Re: Speed King ...g_slice

      Posté par  . Évalué à 3.

      idée de glice
      (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:



      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.



      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  (Mastodon) . Évalué à 3.

        Je crois que ce que tu cherches est GMemVTable:
        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.
  • # Gnome est en danger!

    Posté par  . Évalué à 2.

    Je suis inquiet pour Gnome.

    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  . Évalué à 1.

      Je ne vois pas en quoi Python pose un probleme, et la "force" qui pousse Mono ne l'a pas encore mis dans la distribution Gnome officielle.
      • [^] # Re: Gnome est en danger!

        Posté par  . Évalué à 2.

        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.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.