Discussion :

[Jean-Marc.Bourguet]

Ben je vais essayer de faire un exemple java :
class A
{
void tutu() {...}

void tata() {...}
}

On aura donc 2 liens de la classe A vers ses méthodes, donc 2 x 32 bits

Dans un objet de la classe tu auras (vraissemblablement, il y a d'autres techniques possibles) un pointeur vers une table contenant 2 pointeurs.

class B extends A
{
// on surcharge tutu()
void tutu() {...}
}

Dans un objet de classe B tu auras un pointeur vers une table contenant 2 pointeurs, un vers B::tutu, un vers A::tata.

En C++ on a deux types de fonctions membres, les fonctions membres virtuelles -- qui ont une entrée dans la table -- et les fonctions membres non virtuelles -- qui n'en ont pas. Si une classe n'a pas de fonctions membres virtuelles, elle n'a pas non plus de pointeur vers cette table (qui serait vide). Ce pointeur a un cout qui est particulièrement sensible pour de petits objets. Comme exemple tu as un point en 3 dimentions, un autre exemple où ça coute proportionellement beaucoup sont les wrappers (pour lesquelles Java double la mémoire nécessaire).

[kpouer]

Dans un objet de la classe tu auras (vraissemblablement, il y a d'autres techniques possibles) un pointeur vers une table contenant 2 pointeurs.



Dans un objet de classe B tu auras un pointeur vers une table contenant 2 pointeurs, un vers B::tutu, un vers A::tata.

En C++ on a deux types de fonctions membres, les fonctions membres virtuelles -- qui ont une entrée dans la table -- et les fonctions membres non virtuelles -- qui n'en ont pas. Si une classe n'a pas de fonctions membres virtuelles, elle n'a pas non plus de pointeur vers cette table (qui serait vide). Ce pointeur a un cout qui est particulièrement sensible pour de petits objets. Comme exemple tu as un point en 3 dimentions, un autre exemple où ça coute proportionellement beaucoup sont les wrappers (pour lesquelles Java double la mémoire nécessaire).

Eh bien même dans le cas que tu donnes, ca ne concerne que les objets et non leurs instances non ? Donc je ne vois pas en quoi la mémoire serait tellement affectée par cette histoire de méthodes virtuelles puisque c'est pas multiplié par le nombre d'instances.
Par contre effectivement les wrappers occupent plus de mémoire que le type primitif associé (ce qui est bien logique et il vaut mieux éviter leur utilisation tant qu'on peut.

[gorgonite]

Eh bien même dans le cas que tu donnes, ca ne concerne que les objets et non leurs instances non ? Donc je ne vois pas en quoi la mémoire serait tellement affectée par cette histoire de méthodes virtuelles puisque c'est pas multiplié par le nombre d'instances.

tu veux sans doute faire la distinction entre classe et instance


l'utilisation d'une table virtuelle oblige à stocker un tableau de pointeurs de fonctions par classe, et à effectuer une double indirection pour appeler la méthode...


nb: en Java, c'est double indirection n'est effectuée qu'une seule fois car le bytecode est réécrit à la volée au moment du premier appel afin de mettre directement l'adresse de la méthode appelée... ce qui accélerera le second appel

[Mat.M]

Une des principales faiblesses du Java est de sa récursivité assez faible, compte tenu qu'on travaille sur la JVM, et le fait que quoiqu'on en dise, ce n'est pas si portable que ça. Essyez un peu de développer une belle GUI sous Windows, elle est super, vous la lancez sous Linux elle s'exécute toujours mais
les espacements, tailles des composants ont varié, du coup si votre fenêtre ne peut être agrandie, c'est pas top. Ce n'est qu'un exemple parmi d'autres similaires, ça s'exécute, mais c'est moins bien...

et après on va nous dire que Java et autre c'est portable...

Et moi je me pose des questions : en programmation Windows lorsqu'on fait un clic souris c'est un message système qui est envoyé à l'application.
Bien ; avec Linux cela doit être similaire ( un peu comme Qt qui gère les signaux )
Comment cela est-il géré en interne via la JVM pour une appli Java ?

JVM client 30 secondes
JVM server 22 secondes
C++ 13 secondes

Ok même une applet Java peut parfois être plus rapide que C++

Et as-tu fait des tests avec une interface graphique ?

[epsilon68]

Et as-tu fait des tests avec une interface graphique ?

non, j'avais fait un renderer tres simple en Java (une lumiere, remplissage des faces avec z-buffer) mais c'etait lent. Je voulais faire le meme truc en C++ mais j'ai pas eu le courage, je ne peux donc rien dire.

[adiGuba]

JVM client 30 secondes
JVM server 22 secondes
C++ 13 secondes

Par curiosité (je sais je suis trop curieux ) : quel est le domaine du test ??

et après on va nous dire que Java et autre c'est portable...

Heu... la taille des composants ne doit pas être géré manuellement ! C'est une règle des développements de GUI portable...
Le problème peut se retrouver aussi sous Windows avec des thèmes ou des polices différentes...

En utilisant un layout on évite ce genre de problème !


a++

[Jean-Marc.Bourguet]

Eh bien même dans le cas que tu donnes, ca ne concerne que les objets et non leurs instances non ?

J'ai un probleme de terminologie ici. Dans ce contexte, objet et instance me semblait plus ou moins interchangeable. En tout cas, je n'ai jamais vu parler de l'instance d'un objet.

Pour reexpliquer la chose de maniere plus fondamentale plutot qu'en utilisant une des techniques utilisees. Si on veut de la surcharge determinee dynamiquement (alias dynamic dispatch, ce qui se passe pour les membres virtuels en C++, pour toutes les methodes en Java) il faut que les objets -- ou les instances -- comportent une indication de leur type dynamique. En C++ seules les instances de classes ayant des membres derives ont une telle indication. En Java les instances de toutes les classes doivent avoir cette indication. Et elle prend de la place.

[kpouer]

J'ai un probleme de terminologie ici. Dans ce contexte, objet et instance me semblait plus ou moins interchangeable. En tout cas, je n'ai jamais vu parler de l'instance d'un objet.

Pour reexpliquer la chose de maniere plus fondamentale plutot qu'en utilisant une des techniques utilisees. Si on veut de la surcharge determinee dynamiquement (alias dynamic dispatch, ce qui se passe pour les membres virtuels en C++, pour toutes les methodes en Java) il faut que les objets -- ou les instances -- comportent une indication de leur type dynamique. En C++ seules les instances de classes ayant des membres derives ont une telle indication. En Java les instances de toutes les classes doivent avoir cette indication. Et elle prend de la place.

Oui je me suis mal exprimé quand j'ai dit objet je pensais "Class".
Donc ce que je veux dire c'est que l'histoire des liens vers les méthodes ne concernent que les class et non leurs instances. Donc oui même en admettant que ces liens prennent de la place ca devrait être assez faible car la class n'est chargée qu'une seule fois quelque soit le nombre d'instances. Et puis si on a vraiment envi de faire des économies on déclare la méthode final.
On peut faire un calcul vite fait. Si un projet utilise 2000 classes, 100 méthodes chacunes (de belles classes hein , Ben 4 octets par lien ca fait moins de 800 ko, s'ils sont a double sens ca reste moins de 2 Mo, c'est donc pas un argument très crédible contre Java selon moi

[gorgonite]

On peut faire un calcul vite fait. Si un projet utilise 2000 classes, 100 méthodes chacunes (de belles classes hein , Ben 4 octets par lien ca fait moins de 800 ko, s'ils sont a double sens ca reste moins de 2 Mo, c'est donc pas un argument très crédible contre Java selon moi

dommage pour le calcul, mais il faut regarder de plus près comment est implémentée la réprésentation d'une classe dans la jvm...

la vtable est un tableau d'une structure particulilère contenant de nombreuses informations en plus du simple pointeur de fonctions

du style :
+ pointeur vers la classe à laquelle la méthode appartient
+ flags pour les accès
+ nombre d'arguments
+ pointeur vers une fonction native ou une structure représentant la méthode

etc.

je ne rentrerai pas dans les détails... mais il ne faut pas oublier que les méthodes java doivent aussi être accessibles par introspection et invocation dynamique

[adiGuba]

On peut faire un calcul vite fait. Si un projet utilise 2000 classes, 100 méthodes chacunes (de belles classes hein , Ben 4 octets par lien ca fait moins de 800 ko, s'ils sont a double sens ca reste moins de 2 Mo, c'est donc pas un argument très crédible contre Java selon moi

Ca dépend de ta cible... mais le problème est le même sous Java que sous C++, si ce n'est qu'en Java il faut explicitement indiqué que la méthode n'est pas virtual avec le mot-clef final :

Lorsqu'en C++ on a ceci :

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
// Méthode non virtuelle 
void method() { ... }
 
// Méthode virtuelle :
virtual void method() { ... }
 
// Méthode virtuelle pure :
virtual void method() = 0;

L'équivalent Java est :

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
// Méthode non virtuelle 
public final void method() { ... }
 
// Méthode virtuelle :
public void method() { ... }
 
// Méthode virtuelle pure :
public abstract void method();

C'est juste l'approche de la POO qui n'est pas la même, mais on peut faire la même chose...

a++

[Jean-Marc.Bourguet]

Ca dépend de ta cible... mais le problème est le même sous Java que sous C++, si ce n'est qu'en Java il faut explicitement indiqué que la méthode n'est pas virtual avec le mot-clef final

Je ne connais pas grand chose a Java, mais il me semblait que le seul effet formel de final sur les methodes etait d'empecher qu'elles soient supplantees (overwritten, je ne connais pas la terminologie francophone utilisee en Java). Elles se comportent donc toujours comme des fonctions virtuelles du C++.

[kpouer]

dommage pour le calcul, mais il faut regarder de plus près comment est implémentée la réprésentation d'une classe dans la jvm...

la vtable est un tableau d'une structure particulilère contenant de nombreuses informations en plus du simple pointeur de fonctions

du style :
+ pointeur vers la classe à laquelle la méthode appartient
+ flags pour les accès
+ nombre d'arguments
+ pointeur vers une fonction native ou une structure représentant la méthode

etc.

je ne rentrerai pas dans les détails... mais il ne faut pas oublier que les méthodes java doivent aussi être accessibles par introspection et invocation dynamique

Ca d'accord mais par exemple le nombre d'arguments n'est stocké qu'une fois par méthode, même si la méthode se trouve dans plusieurs classes donc ca ne change pas grand chose.
La question au départ c'était de dire que si on instantie un objet Tutu, comme il hérite obligatoirement de Object, ca lui ajoute des tas de méthodes inutiles et que donc ca prend des ressources. Le fait est que ces ressources supplémentaires sont négligeables car elles ne sont prises qu'une fois par la JVM et non pour chaque instance.

[adiGuba]

Je ne connais pas grand chose a Java, mais il me semblait que le seul effet formel de final sur les methodes etait d'empecher qu'elles soient supplantees (overwritten, je ne connais pas la terminologie francophone utilisee en Java).

Oui (perso je j'utilise plutôt "redéfinir" mais on se comprend c'est le principal ).

Elles se comportent donc toujours comme des fonctions virtuelles du C++.

C'est vrai au niveau du bytecode, mais sauf erreur cela ne l'est plus lors de l'exécution puisque les méthodes final peuvent être "inliné"

A noter que la JVM peut d'ailleurs traiter une méthode virtuelle (non-final) comme une méthode non-virtuelle (final) si elle n'a pas été redéfinie (overwritten ) dans d'autres classes...

a++

[gorgonite]

Ca d'accord mais par exemple le nombre d'arguments n'est stocké qu'une fois par méthode, même si la méthode se trouve dans plusieurs classes donc ca ne change pas grand chose.

ces infos sont stockées au niveau de la classe où est déclarée cette méthode bien sur... après la vtable fait les indirections

La question au départ c'était de dire que si on instantie un objet Tutu, comme il hérite obligatoirement de Object, ca lui ajoute des tas de méthodes inutiles et que donc ca prend des ressources. Le fait est que ces ressources supplémentaires sont négligeables car elles ne sont prises qu'une fois par la JVM et non pour chaque instance.

on n'est pas en SmallTalk, donc ce n'est pas faux... mais il faut signaler qu'ajouter ce genre de petites tables à chaque classe peut, malgré le chargement paresseux, engendrer une surcharge de l'occupation mémoire "virtuelle" (je ne parle pas de ce que fait le GC) qui n'aurait pas lieu en C++
la question est aussi de savoir si ce problème est vraiment critique... et c'est d'autant moins vrai que les classes sont complexes (avec plein de gros attributs non statiques), car chaque instance va se mettre à couter beaucoup, ce qui relativisera le cout de la classe

[Jean-Marc.Bourguet]

La question au départ c'était de dire que si on instantie un objet Tutu, comme il hérite obligatoirement de Object, ca lui ajoute des tas de méthodes inutiles et que donc ca prend des ressources.

Ca ne lui ajoute pas un tas, ca ajoute une marque de type qui fait 4 bytes (et est generalement un pointeur vers une description plus detaillee du type, y compris des pointeurs vers les methodes). Ce marqueur a un cout en espace proportionnellement d'autant plus important que la classe est petite. Ce marqueur n'est la en C++ que si la classe a des membres virtuels.

[gorgonite]

C'est vrai au niveau du bytecode, mais sauf erreur cela ne l'est plus lors de l'exécution puisque les méthodes final peuvent être "inliné"

le mot inliné n'est pas approprié... l'utilisation de l'inlining dépend beaucoup de la méthode

comme je l'ai signalé plus haut, c'est plutot cela qui est effectué... et même sur les méthodes "virtuelles" (nb: je peux l'affirmer, je bosse sur le code d'une jvm sun )

nb: en Java, c'est double indirection n'est effectuée qu'une seule fois car le bytecode est réécrit à la volée au moment du premier appel afin de mettre directement l'adresse de la méthode appelée... ce qui accélerera le second appel

[bafman]

La question au départ c'était de dire que si on instantie un objet Tutu, comme il hérite obligatoirement de Object, ca lui ajoute des tas de méthodes inutiles et que donc ca prend des ressources. Le fait est que ces ressources supplémentaires sont négligeables car elles ne sont prises qu'une fois par la JVM et non pour chaque instance.

comme l'a dit jean marc, le fait d'avoir des methode virtuelles ajoute 1 pointeur par Instance vers le "descripteur" de classe. ce n'est pas grand chose, mais lorsque les données de l'objet ne font que quelques octets, le surcout n'est pas négligeable. L'aventage de C++ dans ce domaine est qu'on peut très bien se passer de ce surcout en n'ayant pas de fonction virtuelle, ce qui n'est pas possible en Java.
de plus, je me demande bien quelle est la taille d'un Object en memoire... toute nos classe heritant de celle ci, si elle a le moindre attribut, on se le recupere sans forcement le vouloir

[kpouer]

comme l'a dit jean marc, le fait d'avoir des methode virtuelles ajoute 1 pointeur par Instance vers le "descripteur" de classe. ce n'est pas grand chose, mais lorsque les données de l'objet ne font que quelques octets, le surcout n'est pas négligeable. L'aventage de C++ dans ce domaine est qu'on peut très bien se passer de ce surcout en n'ayant pas de fonction virtuelle, ce qui n'est pas possible en Java.
de plus, je me demande bien quelle est la taille d'un Object en memoire... toute nos classe heritant de celle ci, si elle a le moindre attribut, on se le recupere sans forcement le vouloir

Ca me parrait logique remarque, faut bien que l'instance sache de quoi elle est une instance. Par contre on ne duplique pas la définition de la classe.
La taille d'un Object je sais pas, mais il n'a aucun champ d'instance donc ne devrait pas induire d'occupation mémoire supplémentaire du fait qu'on hérite de lui.

[gorgonite]

de plus, je me demande bien quelle est la taille d'un Object en memoire... toute nos classe heritant de celle ci, si elle a le moindre attribut, on se le recupere sans forcement le vouloir

un attribut non statique...

suffit de vérifier...
http://java.sun.com/j2se/1.5.0/docs/...ng/Object.html

[adiGuba]

le mot inliné n'est pas approprié... l'utilisation de l'inlining dépend beaucoup de la méthode

J'ai bien dit que les méthodes "pouvait" être "inliné"
Après cela dépend aussi d'autre critère (comme la taille de la méthode, etc.)

Ce marqueur a un cout en espace proportionnellement d'autant plus important que la classe est petite. Ce marqueur n'est la en C++ que si la classe a des membres virtuels.

Tout à fait d'accord sur ce point (bien que j'ignorais cette possibilité du C++). Il est clair que le C/C++ apporte de plus grande possibilité dans la gestion de la mémoire (personne n'a dit le contraire ).

a++