Discussion :

[dabeuliou]

Bonjour à tous,

Je me suis documenté ces derniers jours sur le mécanisme de sérialisation. Il paraît incontestablement formidable sur le plan du service rendu au développeur. J'envisage donc de l'utiliser pour sauvegarder ma structure de données sur le disque. Mais je me pose encore quelques questions relatives aux pertes de performances de ce mécanisme par rapport à un mécanisme plus "manuel" et classique comme on pourrait le coder en C++ par exemple.

Par performances, j'entends particulièrement temps d'exécution et encombrement du fichier sur le disque. J'ai trouvé une info sur le net précisant que sur un cas test, la sérialisation pouvait être environ 2 fois plus lente qu'un mécanisme classique mais je n'ai rien lu sur le rendement en terme de taille de fichier créé. J'imagine qu'il doit bien y avoir un certain prix à payer en contrepartie de la simplicité de codage...

Je serais ravi de lire les appréciations de ceux d'entre vous qui ont eu l'occasion d'évaluer les performances de la sérialisation.

Merci !

[Sanguko]

La serialisation prend effectivement en pratique plus de place

Quand tu utilises la serialisation, par défaut, tu enregistres presque tous les attributs de ta classe, même ceux qui n'ont pas besoin d'être enregistrés. L'effort consiste à supprimer ce que tu ne veux pas enregistrer. Et si tu utilises une classe que tu n'as pas définie toi meme, tu vas peut être enregistrer des informations qui ne t'interesse pas.

Quand tu fais un enregistrement manuel, l'effort consiste à choisir ce que tu veux enregistrer, et comment tu vas le faire. Tu vas donc chercher à ne prendre que le strict necessaire.

[dabeuliou]

As-tu eu l'occasion de faire un comparatif chiffré entre les deux méthodes ?

Si on fait abstraction des champs inutile d'une classe de base qu'on ne maîtrise pas, sais-tu ce que coûte réellement la sérialisation d'un champ par rapport à une bête sauvegarde à la manière de grand-maman ? J'imagine que des infos telles que le nom du champ doivent être sauvées mais y a-t-il autre chose ?

Merci pour ton avis !

[gifffftane]

Je pratique beaucoup la sérialisation, mais je ne suis jamais allé la comparer à d'autres méthodes, particulièrement celles de grand-maman.

Je la trouve très pratique, à condition de faire un fichier = un objet. Ce qui impose une gestion de fichiers. Je pense que d'autres formes ne sont pas très pratiques, parce que de toutes façons le flux de relecture doit relire tout le fichier. La gestion de fichiers n'est pas une lourde charge, à condition de maitriser la classe File ce qui, on l'admettra, est à la portée du premier venu.

Il FAUT placer le serialVersionUID, sinon c'est la panique assurée au bout de 2 jours.

Question optimisation vitesse, un cache d'objet fait éventuellement l'affaire.

Que veux-tu savoir d'autre ?

[dabeuliou]

Je ne suis pas sûr de comprendre ce que tu entends par un fichier = un objet. Dans mon cas, mon appli contient un projet avec sa structure de donnée. L'ensemble devra se sauver sous la forme d'un fichier par projet. Donc pour un objet projet, il y aura un fichier, si c'est cela que tu voulais dire.

Sinon, merci pour vos avis . Je pense me tourner vers la sérialisation qui me paraît vraiment séduisante. Et même si il faut claquer un peu plus d'espace disque, je mise sur le fait que ça reste raisonnable.

[le y@m's]

En ce qui concerne les attributs n'ayant pas besoin d'être sérialisés, le mot clé transient est là pour ça .

[Mister Nono]

Mais je me pose encore quelques questions relatives aux pertes de performances de ce mécanisme par rapport à un mécanisme plus "manuel" et classique comme on pourrait le coder en C++ par exemple.

C'est vraiment une question à se poser de nos jours.

C'était peut-être vrai au début de Java, mais on est à la version 6.

A+