Optimiser la recopie de données entre deux structures

Version imprimable

08/09/2008, 12h42
Cian

Optimiser la recopie de données entre deux structures

Bonjour,
j'ai deux grosses structures de données.
La structure A est envoyée à mon système.
Mon système récupère cette structure A, copie son contenu dans une structure B (plus grosse) et complétera cette structure B avec des données intermédiaires de calcul.
Par la suite, mon système est amené à recopier des éléments de la structure B dans la structure A pour publication vers les clients.

J'aurais souhaité savoir quelle est la manière la plus optimale en terme de perfo pour copier A dans B et B dans A.

Merci :)
08/09/2008, 12h56
ToTo13

Bonjour,

il me semble que le plus simple est de faire des copies de blocs de mémoire. recopie de type memcopy de C/C++.
08/09/2008, 13h54
Cian

Citation:

Envoyé par ToTo13

Bonjour,

il me semble que le plus simple est de faire des copies de blocs de mémoire. recopie de type memcopy de C/C++.

Arf... oui :)
Mais pour compliquer la chose... je suis en JAVA :(
08/09/2008, 17h22
ToTo13

Bonjour,

il doit bien y avoir la même chose... :)
Une petite question dans le forum Java répondra à ton problème (ou tu attends que pseudocode lise ce poste :D)
08/09/2008, 18h49
Cian

Citation:

Envoyé par ToTo13

Bonjour,

il doit bien y avoir la même chose... :)
Une petite question dans le forum Java répondra à ton problème (ou tu attends que pseudocode lise ce poste :D)

j'ai suivi ton conseil et j'ai posé ma question concernant un équivalent du memcpy en JAVA dans le forum JAVA.
Cependant, en terme d'algorithmie pure, je me demandais également si il n'y avait pas un moyen d'optimiser la copie. Exemple, détecter les éléments modifiés pour ne modifier que ce qui est nécessaire : et dans ce cas, je ne me vois pas faire un if A /= B then copy bien sûr... sinon on va assoir les perfs encore plus :mouarf:
08/09/2008, 20h39
millie

Citation:

Envoyé par Cian

Exemple, détecter les éléments modifiés pour ne modifier que ce qui est nécessaire : et dans ce cas, je ne me vois pas faire un if A /= B then copy bien sûr...

Normalement, c'est à toi de définir ce qui est nécessaire de copier complètement ou de garder juste une référence. Par exemple les classes non mutables peuvent être copiées simplement par référence au lieu d'être copiées complètement.

Mais il n'y a pas de signature en Java qui indique qu'une classe est non mutable, c'est donc à toi d'implémenter la méthode clone()
09/09/2008, 12h26
pseudocode

Citation:

Envoyé par ToTo13

Une petite question dans le forum Java répondra à ton problème (ou tu attends que pseudocode lise ce poste :D)

:P

Citation:

Envoyé par Cian

Cependant, en terme d'algorithmie pure, je me demandais également si il n'y avait pas un moyen d'optimiser la copie. Exemple, détecter les éléments modifiés pour ne modifier que ce qui est nécessaire

Hum.. implémenter son propre COW (copy-on-write) en Java permettrait peut-etre de gagner un peu de performance mais au détriment de la complexité du code (sans parler de problemes de multi-threading).

Les mécanismes de serialisation/déserialisation de Java permettent de dupliquer (plus ou moins) facilement des instances composites. En terme de performance ce n'est pas très rapide, mais on peut utiliser des tactiques pour ameliorer les choses (nursery, background thread + pattern futur)

Sinon, il faudrait remonter a la conception de ton appli pour eviter d'avoir beson d'un clone "complet" de ta structure
09/09/2008, 13h48
Cian

Citation:

Envoyé par pseudocode

Les mécanismes de serialisation/déserialisation de Java permettent de dupliquer (plus ou moins) facilement des instances composites. En terme de performance ce n'est pas très rapide, mais on peut utiliser des tactiques pour ameliorer les choses (nursery, background thread + pattern futur)

Merci. Je ne suis pas une spécialiste mais je vais me renseigner sur ces sujets.

Citation:

Envoyé par pseudocode

Sinon, il faudrait remonter a la conception de ton appli pour eviter d'avoir beson d'un clone "complet" de ta structure

Hum... oui je suis bien d'accord avec toi. C'est un choix que je n'ai toujours pas compris... Malheureusement, c'est un héritage de mes prédécesseurs...Aujourd'hui je me vois mal bouger ce design car çà remettrait en cause bcp de choses et de $. Dans un premier temps, on va chercher à optimiser le code. Si on n'obtient pas de résultat significatif alors il faudra sans doute se résoudre à des solutions de re-design effectivement.